2025-04-01 21:01:03 <Kladky> when trying to upgrade deno, it fails to build due to undefined systems when expecteding icu 76, but icu-dev-76 is pulled, so idk why that would fail
2025-04-01 21:01:05 <Kladky> https://gitlab.alpinelinux.org/Matthias/aports/-/jobs/1792220#L1158
2025-04-01 21:02:40 <Kladky> or maybe the better approach for now is to just disable tests, idk
2025-04-01 21:02:49 <Kladky> and keep the current version
2025-04-01 22:37:51 <fossdd[m]> after !82206 and !82208 we could theoretically drop llvm/clang 17
2025-04-02 00:49:56 <broski[m]> From Trusted and Vouched Dealers... (full message at <https://matrix.org/oftc/media/v1/media/download/AVZh4XX8Q3Z8iU1EOPfrHvUAs6x62jD35CErcQMm_JFr_nv7rsFqdMvCGdvk73rlF622-_HGUeZHcMlvA32d5N9CeWPBLyOAAG1hdHJpeC5vcmcvWU5jeERRUXhpdmZBVG5mdnlxa3dybVp1>)
2025-04-02 00:54:08 <craftyguy[m]> @ikke @ncopa ^^
2025-04-02 05:38:22 <Saijin_Naib[m]> ikke!82037 is ready for review/merge, and then I guess subsequent move to Community, if you wish, since it works great on my two craptops here the past few days
2025-04-02 05:57:27 <fossdd[m]> pj
2025-04-02 07:52:54 <f_> fossdd[m]: don't see any spam and pj is not op so nothing can be done I guess
2025-04-02 07:53:09 <f_> besides the matrix.org bridge will be going down anyway
2025-04-02 07:53:34 <fossdd[m]> the spam was on the matrix side and pj is op on the matrix side
2025-04-02 07:53:37 <fossdd[m]> but its removed now
2025-04-02 07:53:40 <f_> oh, ok nice
2025-04-02 08:31:38 <rhizoome> I built electron and got signal-desktop back. many thanks to the electron maintainer!
2025-04-02 08:38:14 <quinq> Praise “secure” applications working on a web browser :>
2025-04-02 08:41:01 <rhizoome> Electron is a beast 42000 objects to build, 2.2 GB in ccache!
2025-04-02 08:46:24 <quinq> :D
2025-04-02 09:02:06 <f_> No wonder it's so fast at runtime!
2025-04-02 09:54:06 <Kladky> I think !82234 is a sensible solution while we figure out how to get the latest deno release to build
2025-04-02 10:34:45 <hwspeedy> WANTED: Alpine Package Maintainer for GUI/CLI program - hardinfo2 - system information and benchmarks.
2025-04-02 10:35:33 <hwspeedy> See https://hardinfo2.org - source code: https://github.com/hardinfo2/hardinfo2 - contact create issue on github, thanx.
2025-04-02 10:46:54 <hwspeedy> Build instructions for Alpine Linux/PostMarketOS - https://github.com/hardinfo2/hardinfo2/discussions/87 - see bottom.
2025-04-02 10:48:59 <fossdd[m]> hwspeedy: the easiest would be to start a package yourself https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package :p
2025-04-02 10:54:54 <hwspeedy> Thanx, I know - but you run out of time as project maintainer - sofar it is used from 91 different distros, 11 architectures - so hoping a nice Alpine package maintainer would take the challenge and enable it for postmarketos as well, thanx.
2025-04-02 11:00:24 <f_> hwspeedy: best to package it yourself I believe. Then later if someone else wants to takeover they can.
2025-04-02 11:04:40 <fabricionaweb> open an issue, sometimes people pick requests from the issues
2025-04-02 11:07:27 <f_> that works too
2025-04-02 11:47:44 <hwspeedy> Thanx, Created Alpine Packaging issue: https://gitlab.alpinelinux.org/alpine/aports/-/issues/17052
2025-04-02 13:21:50 <elagost> could someone review this mr? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/81012
2025-04-02 15:37:01 <jahway603[m]> I'm trying to better understand the upgrade from icu 74.2 -> 76.1, as https://gitlab.alpinelinux.org/alpine/aports/-/commit/ba5442d4932d09139948f4e9d8d106c75c501cc7?page=3 shows that php83 was rebuilt against icu 76.1, but I keep having riscv pipelines failing and https://pkgs.alpinelinux.org/packages?name=php83&branch=edge&repo=&arch shows 8.3.19-r0 for riscv while it shows the rebuilt one for all the other architectures. How does
2025-04-02 15:37:01 <jahway603[m]> the riscv php83 get updated?
2025-04-02 15:37:44 <fossdd[m]> the builder is still busy see https://build.alpinelinux.org/
2025-04-02 15:37:49 <fossdd[m]> but at this point i think its stuck
2025-04-02 16:04:29 <mio> jahway603[m]: it gets updated the same way as the other arches. builder's running now but it'll take some time for it to get to community/ packages. just check back later
2025-04-02 16:11:13 <pcarrier> ahoy! an idle merge request notification invited me to come here, so here I am. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/80024
2025-04-02 16:18:14 <Kladky> Funny how as soon as deno builds are fixed, something else goes and breaks
2025-04-02 16:21:36 <Kladky> I wonder if paast 404 is to do with ip range ban due to AI crawlers recently
2025-04-02 16:21:40 <Kladky> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/passt/passt-2025.03.20-r0.log
2025-04-02 16:21:56 <Kladky> Since I can download the archive with curl no problems
2025-04-02 16:34:34 <Kladky> Would reverting the commit where it is upgraded cause a rebuild?
2025-04-02 16:35:13 <Kladky> omni
2025-04-02 16:35:24 <ikke> If pkgver and rel match what's in the repo, then not
2025-04-02 16:52:50 <PabloCorreaGomez[m]> ikke: sertonix ncopa did you receive the poll I sent you for the APK meeting? Or maybe there were some issues with the bridge?
2025-04-02 16:55:20 <ikke> PabloCorreaGomez[m]: received it
2025-04-02 17:19:48 <f_> speaking of bridges do you still want one after the matrix.orf bridge's shut down? Just curious  
2025-04-02 17:19:53 <f_> matrix.org*
2025-04-02 17:24:26 <f_> actually maybe wrong channel
2025-04-02 17:24:33 <f_> I'll ask in -infra
2025-04-02 17:56:59 <Saijin_Naib[m]> @f_ i would appreciate a matrix bridge. Saves me setting up a BNC
2025-04-02 18:17:50 <f_> Saijin_Naib[m]: we moved to -infra
2025-04-02 18:35:39 <Kladky> !82256
2025-04-02 18:47:03 <Kladky> It's strange that only the x86(_64) builders have timed out, despite the others succeeding
2025-04-02 18:52:15 <AledCuda[m]> Is it possible to bump up the CI time allocation for a given pull request to aports
2025-04-02 18:52:54 <ikke> AledCuda[m]: you have to increase it for your fork
2025-04-02 18:53:16 <AledCuda[m]> I'm attempting to bring up alpine on the zynqmpsoc but the 1hr timeout is just under whats needed for the aarch64 runner to finish building the kernel https://gitlab.alpinelinux.org/ld-cd/aports/-/pipelines/312819
2025-04-02 18:53:18 <AledCuda[m]> Ah ok
2025-04-02 18:53:41 <AledCuda[m]> I presume passing in CI is a prerequisite for getting merged?
2025-04-02 18:54:21 <ikke> Except for certain exceptions, yes
2025-04-02 18:58:32 <AledCuda[m]> Ok I believe I have set that correctl
2025-04-02 18:59:10 <AledCuda[m]> This is my first time contributing to alpine
2025-04-02 18:59:30 <AledCuda[m]> is there any other information I should include about the change beyond what I've included here: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/82218
2025-04-02 19:00:01 <ikke> 1) you should increase the `pkgrel` field
2025-04-02 19:00:26 <ikke> 2) Updating the linux-lts package also requires to rebuild some out-of-tree modules
2025-04-02 19:01:02 <AledCuda[m]> Should I squash that into a single commit with the config change?
2025-04-02 19:01:08 <AledCuda[m]> Hmm
2025-04-02 19:01:11 <ikke> the pkgrel bump, yes
2025-04-02 19:01:29 <ikke> The _krel bump for those other modules requires separate commits
2025-04-02 19:01:53 <AledCuda[m]> If 2) is the case and I have one other change to the config should I close this and reopen with that change as well
2025-04-02 19:01:58 <AledCuda[m]> or favor smaller change sets
2025-04-02 19:03:06 <ikke> You don't need to recreate MRs, and these changes should be a single MR
2025-04-02 19:03:33 <AledCuda[m]> Sounds good
2025-04-02 19:03:45 <AledCuda[m]> is there a list of out of tree modules I can reference somewhere?
2025-04-02 19:05:13 <ikke> All *-lts packages that have a _krel field
2025-04-02 19:05:24 <ikke> https://tpaste.us/4vrX 
2025-04-02 19:08:53 <AledCuda[m]> One commit updating the LTS package and _pkgrel and then one commit bumping the _krels all in one MR?
2025-04-02 19:09:52 <ikke> one commit per package
2025-04-02 19:10:22 <ikke> AledCuda[m]: https://gitlab.alpinelinux.org/alpine/aports/-/commits/master?search=kernel
2025-04-02 19:23:48 <AledCuda[m]> Thanks
2025-04-02 19:25:09 <ikke> Kladky: that revert is no longer necessary
2025-04-02 19:26:12 <Kladky> ikke: do you know what the issue was then?
2025-04-02 19:27:00 <ikke> no
2025-04-02 19:31:33 <Kladky> Seems like it's art_standalone's turn to cause builders to fail
2025-04-02 19:32:18 <Kladky> And zaproxy too
2025-04-02 19:56:24 <Kladky> Or I guess not...
2025-04-02 20:29:27 <AledCuda[m]> Alright assuming the CI passes does this look correct: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/82218
2025-04-02 21:50:14 <AledCuda[m]> Do I need to rerun the pipeline everytime I rebase?
2025-04-02 23:36:43 <AledCuda[m]> https://gitlab.alpinelinux.org/ld-cd/aports/-/jobs/1794050
2025-04-02 23:36:51 <AledCuda[m]> Alright it passes in CI
2025-04-02 23:37:18 <AledCuda[m]> I think this is ready to merge if anybody has the bandwidth
2025-04-02 23:37:35 <AledCuda[m]> And if the changes make sense
2025-04-02 23:38:15 <AledCuda[m]> I feel bad for sucking down so many hours of CI time
2025-04-03 13:43:59 <calebccff> howdy folks, possibly im missing something here but I think Thunderbird needs to be rebuilt against icu-lib-76, this seems to be blocking upgrades of a bunch of things for me. I guess the idea was to do this as part of the 137 upgrade?
2025-04-03 13:45:26 <calebccff> mrtest add -a 82128 will hopefully get me through :D
2025-04-03 13:48:20 <ikke> calebccff: what arch?
2025-04-03 13:48:50 <calebccff> ikke: aarch64
2025-04-03 13:48:57 <ikke> can confirm on x86_64 as well
2025-04-03 13:49:15 <ikke> I indeed see there is no rebuild commit
2025-04-03 13:49:51 <ikke> ptrc: ^?
2025-04-03 13:50:10 <ptrc> calebccff: that was the idea indeed
2025-04-03 13:50:20 <ptrc> but then i got blocked on trying to get s390x/armhf to work..
2025-04-03 13:50:26 <ptrc> i'll just push the update for now
2025-04-03 13:50:28 <calebccff> ahh
2025-04-03 13:50:31 <calebccff> tysm!
2025-04-03 16:39:15 <sertonix[m]> Can anyone upgrade xz to 5.8.1?
2025-04-03 16:46:22 <rhizoome> sertonix[m]: like so?
2025-04-03 16:46:22 <rhizoome> » xz --version
2025-04-03 16:46:22 <rhizoome> xz (XZ Utils) 5.8.0
2025-04-03 16:47:25 <rhizoome> there is no never xz avaible.
2025-04-03 16:47:29 <sam_> yes, there is
2025-04-03 16:47:39 <sam_> they're asking someone to update the packaging to reflect that
2025-04-03 16:48:01 <rhizoome> ok. I'll do that. just a moment.
2025-04-03 16:52:59 <rhizoome> sertonix[m]: here is the MR: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/82279
2025-04-03 19:53:17 <AledCuda[m]> Does enabling the FPGA config framework as a module (https://elixir.bootlin.com/linux/v5.14.21/source/drivers/fpga/Kconfig) on the lts-arm kernel for the SoC FPGAs alpine supports make sense
2025-04-03 19:53:53 <AledCuda[m]> I think that would be Arria 10 and ZynqMP
2025-04-03 23:49:13 <sertonix[m]> Could !76708 be merged please? The maintainer has added a thumbs up.
2025-04-04 06:14:44 <markand> o/
2025-04-04 06:14:53 <markand> can someone take a look at the aging !79397 ?
2025-04-04 22:21:11 <rhizoome> gitlab ci seems to be broken: ERROR: Job failed (system failure): prepare environment: waiting for pod running: timed out waiting for pod to start.
2025-04-04 22:49:43 <rhizoome> CI works again, to take a break and walk the dog has solved the problem
2025-04-05 09:58:50 <sigirnog> "switch_root: can't execute '/sbin/init': Symbolic link loop" huh?
2025-04-05 09:58:54 <sigirnog> -rwxr-xr-x 1 root root 27233 Apr  5 16:46 init
2025-04-05 09:58:57 <sigirnog> lrwxrwxrwx 1 root root 12 Apr  5 16:46 bin/sh -> /bin/busybox
2025-04-05 09:59:01 <sigirnog> -rwxr-xr-x 1 root root 808712 Apr  5 16:46 bin/busybox
2025-04-05 09:59:58 <sigirnog> oops wrong channel
2025-04-05 20:02:18 <amf3> Hi fossdd[m], no rush in replying.  I can check the IRC archive after Monday. When you have a moment, could you take a look at aports MR 82091? I also noticed there’s an open MR for upgrading cloud-init to 24.4.  Let me know if I can help out with that.  Thanks.
2025-04-05 20:05:23 <ikke> !82091
2025-04-05 21:15:35 <AledCuda[m]> Relaying my question from !82218 would it make sense to add support for loading the FPGA bitstream in the same commit 
2025-04-05 21:15:47 <AledCuda[m]> I think it would add ~16k to the modloop
2025-04-06 07:43:56 <anjan> can someone please review https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/82032
2025-04-07 03:28:27 <qaqland> so many MRs, what can I do for aports.git?
2025-04-07 07:17:15 <rhizoome> riscv64 is fixed, thanks very much to everybody who worked on that! all my pipelines are green!
2025-04-07 07:28:22 <ncopa> hi! im back
2025-04-07 07:30:07 <f_[m]> welcome back ncopa
2025-04-07 09:50:46 <rhizoome> On !80633 I rebased and re-run the pipelines it should be ready to merge now, I hope :-)
2025-04-07 10:07:37 <dopice_> hi! I'm pretty new here and have a quick question when it comes to the contributions. Does all MRs require an Issue to be created in advance? I'm looking at submitting suggestion to a package in community aports.
2025-04-07 10:08:24 <dopice_> or can I propose my changes directly in a MR?
2025-04-07 10:15:10 <rhizoome> Just an MR. Issues for bugs or managing larger efforts.
2025-04-07 10:15:29 <dopice_> roger that! thanks a lot!
2025-04-07 10:16:37 <rhizoome> Except you are you want to ask something before you do the work.
2025-04-07 10:17:07 <rhizoome> s/you are//
2025-04-07 10:23:44 <pabloyoyoista|m> ncopa ikke sertonix%5Bm%5D fabled fossdd APKv3 meeting scheduled for Thursday :)
2025-04-07 10:25:27 <dopice_> it's a small feature so even if it's rejected I believe it's easier for all involved with just a MR.
2025-04-07 13:39:02 <mio> ncopa: fwiw, left !82259 !82261 ... probably the last of the icu 76 rebuilds
2025-04-07 13:39:57 <mio> (or the ones that initially had issues)
2025-04-07 16:30:51 <AledCuda[m]> !82218 Rebased, ready to merge once the CI finishes in ~3h but I expect it to pass like last time
2025-04-07 17:20:35 <psykose> you can just skip the ci since it's the kernel
2025-04-07 18:37:25 <markand> anyone for !79397 please?
2025-04-07 18:40:11 <ikke> It's a huge MR..
2025-04-07 18:40:26 <ikke> With a number of custom licenses
2025-04-07 18:52:31 <ikke> markand: we have removed packages because they were BUSL licensed, so it would not be consistent to allow these custom non-commercial usage licenses projects
2025-04-07 20:24:53 <AledCuda[m]> !82218 is ready to merge I believe if anyone has the BW to review
2025-04-07 20:25:18 <ikke> AledCuda[m]: The maintainer (ncopa) is the one to review that
2025-04-07 20:57:17 <markand> <3 
2025-04-08 07:26:29 <ncopa> AledCuda[m]: I usually do kernel config changes together with version bumps
2025-04-08 07:28:30 <AledCuda[m]> Sounds good, this isnt a rush, I've had to swap to the vendor kernel anyways for the time being to track down a regression in the FPGA manager subsystem
2025-04-08 07:28:43 <AledCuda[m]> Should I leave the PR open or close it out?
2025-04-08 11:59:32 <ncopa> it was merged so you dont need do anything. thanks!
2025-04-08 12:17:28 <Ermine> bl4ckb0ne: !82489
2025-04-08 12:48:41 <ncopa> im gonna merge a new abuild version now. look out for breakages
2025-04-08 13:08:00 <ptrc> fwiw, i've rebuilt most of main with latest abuild master (+ my patches of which one is now merged) and rootbld
2025-04-08 13:08:17 <ptrc> so hopefully nothing breaks too much ^^
2025-04-08 16:15:19 <Kladky> Could someone please look at !81048, !81372, !78021, or !81917 ? Thanks in advance.
2025-04-08 16:28:48 <fossdd[m]> oh and !81962 would be nice :)
2025-04-08 20:02:49 <ser3> I'm getting 500 errors from gitlab when trying to create an MR. Is this a known issue?
2025-04-08 20:03:07 <ser3> I've tried 3 different browsers in case it was something in the request.
2025-04-08 20:03:30 <rhizoome> ser3: usually it is because your branch is far behind master. rebase your branch on master.
2025-04-08 20:09:10 <ser3> Kth
2025-04-08 20:23:45 <ptrc> ooh, there's a new spam going out to addresses scraped from Repology ( which includes most aports maintainers )
2025-04-08 20:23:55 <ptrc> but they messed up the scam and forgot to attach a file
2025-04-08 20:24:23 <ptrc> so it
2025-04-08 20:24:37 <ptrc> it's just "please find attached" with no attachment https://ptrc.gay/OfarrykJ
2025-04-08 20:24:37 <ptrc> lol
2025-04-08 20:25:49 <psykose> phew, my alibaba trade manager account is still safe
2025-04-08 21:56:58 <Ermine> can I cross compile a package with abuild?
2025-04-08 22:05:08 <khem> Ermine: I use qemu usermore and docker/podman when in need to cross compile 
2025-04-08 22:06:44 <ptrc> i mean, that's not exactly crosscompiling
2025-04-08 22:07:34 <ptrc> but for emulated compiling there's also just `CBUILD_ARCH=aarch64 abuild rootbld`
2025-04-08 22:07:50 <khem> yes I understand :)
2025-04-08 22:22:21 <AledCuda[m]> ncopa: for the future would it be easier if I opened an issue for kernel config changes so that its tracked for the next point release?
2025-04-08 23:23:52 <craftyguy[m]> hmm a CI runner used for build testing seems to be failing with some "insufficient memory" error: https://gitlab.alpinelinux.org/craftyguy/aports/-/jobs/1801842
2025-04-09 00:56:46 <Ermine> ptrc: with your command, build fails due to missing aarch64-alpine-linux-musl-strip, though it's available on the host
2025-04-09 05:45:01 <markand> ikke, so maybe a new repository folder?
2025-04-09 05:45:19 <markand> like nonfree, but some people are enjoying retroarch on postmarketos
2025-04-09 05:45:33 <ikke> We used to have that, but it was removed due to attrition
2025-04-09 05:46:12 <markand> basically libretro devs are using either MIT LGPL and such but they just a dd a NC clause to avoid legal issues of people selling machines with prebuilt software
2025-04-09 05:46:30 <markand> or GPL 
2025-04-09 05:51:23 <markand> it's still opensource software, it's not like nvidia drivers and it would be a shame to start an external prpoject like rpmfusion just to bring "custom" licensed software
2025-04-09 05:52:21 <psykose> i think the entire argument people try to make is that adding an -NC makes it not opensource software
2025-04-09 05:54:44 <markand> then I think I'll remove all libretro- and start hosting the packages elsewhere 
2025-04-09 05:56:19 <ikke> It's a bit more nuanced, at least from my point of view
2025-04-09 05:57:05 <ikke> We are relying on the spdx license list at the moment, but that might exclude some software that we may still think is fine, but we need to have a clear policy to state what is acceptable and not
2025-04-09 05:58:32 <psykose> i don't think the spdx part is relevant, that's just tagging things and not the meat of the discussion
2025-04-09 05:58:58 <psykose> like when terraform was relicensed to busl it was removed.. because busl is considered not open source.. because of the clause about non-commercial requirement
2025-04-09 05:59:02 <psykose> this is kind of exactly the same thing
2025-04-09 05:59:06 <sertonix[m]> Ermie: I think the correct command is CBUILD=aarch64 abuild rootbld. And to answer your original question: abuild can do proper cross compilation but most APKBUILDs aren't compatible.
2025-04-09 05:59:15 <psykose> whether the licence is in an spdx list or not is a separate thing
2025-04-09 06:00:03 <sertonix[m]> Ermine: See my message above (typo in the name)
2025-04-09 06:00:14 <psykose> (and i'm not saying whether it should or shouldn't be removed, but this case is completely identical to the terraform one, it's the same kind of licence clause)
2025-04-09 06:01:53 <markand> I don't fully understand which statement indicates that a NC clause tags a software not opensource, it justs a clause, you're still free to change the code to your needs
2025-04-09 06:03:14 <markand> even FSF and OSI don't really define opensource the same way
2025-04-09 06:03:38 <markand> otherwise, we couldn't either put CC-BY-SA-CC stuff either
2025-04-09 06:03:44 <markand> NC*
2025-04-09 06:04:13 <psykose> are you saying you haven't read the debates around this topic specifically around e.g. whether licences like BUSL-1.1 are considered open source, and why or why not?
2025-04-09 06:06:31 <markand> I don't really care at all about ubsl
2025-04-09 06:06:49 <psykose> it's not busl specific
2025-04-09 06:08:17 <psykose> i'm just pointing out that 'its open source even if theres a noncommercial clause and you cant sell the code' is a controversial statement and there will be many people saying it's true and many people disagreeing with it, and that's where the discussion and the need for a policy comes from
2025-04-09 06:08:31 <psykose> when you say 'its still open source even with the clause', you pick one interpretation
2025-04-09 06:09:34 <psykose> alpine historically has actually picked the opposite, and that's why terraform (and similar things) were removed
2025-04-09 06:09:43 <psykose> i don't think it's a formally-written policy in some form unless i missed it
2025-04-09 06:10:21 <psykose> i'm not saying which is the correct representation, just making you aware that it's not as simple as just saying what you believe the correct one is, and this is a messy area too many people have fought over in general
2025-04-09 06:29:20 <sam_> yes
2025-04-09 06:29:35 <sam_> and while one may have opinions on whether it's practical and such, there's a lot to it, and more than just vibes on if it feels open
2025-04-09 06:29:46 <sam_> (including arguments for why various criteria exist for something to be a foss licence)
2025-04-09 11:40:17 <PureTryOut> While updating Qt6WebEngine to 6.9.0 it's failing on at least aarch64 with "selected processor does not support `udot v0.4s,v4.16b,v16.16b'". Does anyone know what this means?
2025-04-09 12:02:56 <rhizoome> PureTryOut: it seems to be a processor instruction 
2025-04-09 12:03:44 <rhizoome> somebody added an optimization? maybe it can be disabled?
2025-04-09 12:05:15 <rhizoome> https://developer.arm.com/documentation/ddi0602/2022-09/SIMD-FP-Instructions/UDOT--vector---Dot-Product-unsigned-arithmetic--vector--
2025-04-09 12:39:18 <funderscore> "Is there any way to retry a failed build in http://build.alpinelinux.org/? Seems util-linux is stuck on a racy test"
2025-04-09 13:44:18 <f_[m]> pabloyoyoista|m seems like the bridge is having some issues, it's very busy  after the restart
2025-04-09 13:44:20 <f_[m]> Hopefully it's back up to speed later
2025-04-09 13:44:20 <f_[m]> I'll restate your question
2025-04-09 13:44:22 <f_[m]> pabloyoyoista|m actually regarding your actual Q, #alpine-commits's algitbot could be it? But wait for the irc to be fully back up first ;)
2025-04-09 13:44:22 <f_[m]> that said messages should be queued in by the bridge for sending once it finds time to connect you and I
2025-04-09 13:44:35 <f_> oopsie
2025-04-09 13:44:41 <invoked> re: licensing, rather than formal policy it probably would make sense to write a position statement. like, we generally follow the spdx list, except in unusual situations where exceptions have been clearly discussed in gitlab somewhere. i doubt any of us are lawyers, so these are judgment calls that making said things available don't put alpine nor its users in some murky legal
2025-04-09 13:44:43 <invoked> situation
2025-04-09 13:44:52 <PureTryOut> rhizoome: I guess so. Seems to come from a third-party dependency in chromium, libyuv. Not sure how to disable it
2025-04-09 13:46:20 <rhizoome> It says Optimized for Neon/SVE2/SME on Arm. on their page.
2025-04-09 13:47:54 <rhizoome> Its a very much google kind of project... hmm
2025-04-09 13:52:03 <rhizoome> PureTryOut: Qt6 does not include the whole of chromium right?
2025-04-09 13:56:53 <rhizoome> https://tpaste.us/Yqe4
2025-04-09 13:58:01 <rhizoome> PureTryOut: LIBYUV_DISABLE_NEON
2025-04-09 13:58:32 <rhizoome> PureTryOut: that need to be defined, to avoid using udot.
2025-04-09 14:00:27 <rhizoome> PureTryOut: The documentation says that LIBYUV_DISABLE_NEON is also an environment variable
2025-04-09 14:01:13 <rhizoome> PureTryOut: https://chromium.googlesource.com/libyuv/libyuv/+/8c48036d15d66ae951edbbeccfd3d0f268d589b9/docs/environment_variables.md
2025-04-09 14:02:04 <rhizoome> PureTryOut: And there is also a more specific variable LIBYUV_DISABLE_NEON_DOTPROD
2025-04-09 14:03:14 <rhizoome> PureTryOut: but I am not sure if we really want to do that. NEON should be availble on arch64 not?
2025-04-09 14:14:24 <rhizoome> CI seems to be broken: ERROR: Job failed (system failure): prepare environment: setting up credentials: Post "https://10.96.0.1:443/api/v1/namespaces/gitlab-ci/secrets": dial tcp 10.96.0.1:443: connect: no route to host. Check https://docs.gitlab.com/runner/shells/index.html#shell-profile-loading for more information
2025-04-09 16:09:29 <jahway603[m]> How do I update the e-mail address which Alpine Package DB <noreply@alpinelinux.org> sends "One or more of your Alpine packages have been flagged out of date" e-mails to? I figured this would have been updated when I updated my e-mail at the Alpine Gitlab a month or so ago. What am I missing?
2025-04-09 16:10:55 <ikke> jahway603[m]: it's the address in the APKBUILD maintainer field 
2025-04-09 16:17:15 <elagost> would anyone be able to review !82241 ? Thanks.
2025-04-09 18:06:47 <pabloyoyoista|m> Is there any way to retry a failed build in http://build.alpinelinux.org/? 
2025-04-09 18:06:49 <pabloyoyoista|m> Seems util-linux is stuck on a racy test
2025-04-09 18:06:51 <f_> messages incoming please ignore
2025-04-09 18:08:11 <f_> ignore ^ this one too, wrong chan
2025-04-09 18:13:01 <rhizoome>  pabloyoyoista|m no the builders is were the magic happens and you need to be magician to get access. :-) But you can mention a problem in this channel, just prepare to wait. 
2025-04-09 18:13:53 <f_> rhizoome: I think it was a delayed message
2025-04-09 18:15:41 <rhizoome> f_ yes I saw this message twice, that why I answered. Why does this happen? I am back in IRC after many years.
2025-04-09 18:15:56 <f_> rhizoome: postmarketOS Matrix bridge had a reboot
2025-04-09 18:16:08 <f_> and this delayed a bunch of messages
2025-04-09 18:16:23 <f_> should be back up to speed by tomorrow I hope
2025-04-09 18:16:35 <rhizoome> I see.
2025-04-09 18:16:42 <abby> when the consistency is eventual
2025-04-09 18:23:33 <f_> abby: I mean it's still saner than the matrix.org bridge ;p
2025-04-09 18:24:04 <f_[m]> very sane yes
2025-04-09 18:24:27 <f_> Eventually it might probably bridge all alpine channels
2025-04-09 18:24:43 <f_> right now only a few people (postmarketOS team) have access to it
2025-04-09 18:24:54 <f_> (and it bridges the pmOS channels)
2025-04-09 18:25:31 <rhizoome> I used matrix in the past, because I needed to be on this channel maybe twice a year. Now I use a bouncer.
2025-04-09 18:26:55 <f_> I like irc better too
2025-04-09 19:01:19 <fossdd[m]> can somebody quickly review and merge !82581
2025-04-09 19:01:43 <fossdd[m]> totally missed that one 😅
2025-04-09 19:05:32 <ikke> fossdd[m]: Would be helpful to have a motivation in the commit messages
2025-04-09 19:08:30 <fossdd[m]> oh yeah i cleaned the commit up
2025-04-09 21:02:18 <fossdd[m]> ikke: if you have a spare second, can you take a look?
2025-04-09 21:31:36 <fossdd[m]> or ptrc :3
2025-04-09 21:31:44 <ptrc> i have been summoned
2025-04-09 21:40:15 <fossdd[m]> can you take a look at !82581? ^^
2025-04-09 22:23:40 <ptrc> looks good at first glance, but i can't quite check if it doesn't break anything
2025-04-09 22:28:47 <psykose> it's already broken
2025-04-09 22:28:49 <psykose> that fixes it
2025-04-09 22:30:00 <psykose> x86_64 edge just hasn't uploaded, but on e.g. aarch64 if you install `openssh-server` it is missing -auth since it's in just base `openssh`
2025-04-09 22:30:26 <psykose> so if someone upgrades and they have only -server the daemon is broken on restart
2025-04-09 22:32:27 <ptrc> ah
2025-04-09 22:32:39 <psykose> might even be broken before restart since the -session binary will be different
2025-04-09 22:32:48 <psykose> and use the extra -auth already
2025-04-09 22:32:49 <psykose> not sure
2025-04-10 06:56:35 <ncopa> anybody has idea how to fix 32 bit rust to not SIGABRT when building firefox?
2025-04-10 06:57:11 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/issues/17072
2025-04-10 07:14:28 <dne> looks like dl-cdn.alpinelinux.org is "behind" on packages, at least from where I sit
2025-04-10 07:14:55 <dne> e.g. https://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/APKINDEX.tar.gz has a timestamp from ~24h ago
2025-04-10 07:19:02 <fossdd[m]> uhh is it reported to upstream rust/
2025-04-10 07:19:14 <dne> fossdd[m]: btw, did you see: "Due to an error in the release process, the recent Portable OpenSSH release identifies itself as 10.0p2 rather than the intended 10.0p1."?
2025-04-10 07:37:39 <fossdd[m]> uh no, but i dont think it matters?
2025-04-10 07:38:43 <fossdd[m]> but nice to know i guess
2025-04-10 07:40:46 <ncopa> dne its due to build failure https://build.alpinelinux.org/
2025-04-10 07:40:58 <ncopa> will hopefully get time later today to have a look at it
2025-04-10 07:41:11 <ncopa> but today is packed with meetings of all sorts
2025-04-10 07:43:34 <dne> ok!
2025-04-10 13:02:20 <ikke> We just passed 42k merged MRs in gitlab
2025-04-10 13:03:27 <lotheac> congrats :)
2025-04-10 13:34:31 <qaqland> got 500 when create MR
2025-04-10 13:34:48 <ikke> qaqland: Update your forks master branch
2025-04-10 13:35:32 <ikke> Or use glab to create the MR
2025-04-10 13:39:20 <qaqland> ikke: thx, it works
2025-04-10 13:43:17 <dne> !82520 is ready after riscv64 finally got enough hours to complete CI… (already merged to 3.20 and edge)
2025-04-10 14:06:53 <ikke> pabloyoyoista|m: Do we have the apkv3 meeting now?
2025-04-10 14:07:37 <pabloyoyoista|m> Yes, I just jumped out of another meeting
2025-04-10 14:07:48 <pabloyoyoista|m> ncopa fabled
2025-04-10 14:08:24 <fabled> Will join soon.
2025-04-10 22:13:33 <candrew> thank you everyone for your great work with the MRs!
2025-04-10 22:13:36 <candrew> i appreciate it
2025-04-11 01:27:54 <jahway603[m]> Can someone please merge !82521 and !82522 when they get a chance? Thanks.
2025-04-11 02:11:02 <jahway603[m]> Question about flagging packages out-of-date. I created a Fedora account to flag in Anitya. After logging in, Anitya has Monero 0.18.4.0 [https://release-monitoring.org/project/15526/] and Alpine is set under distro mappings there, but pkgs.alpinelinux.org has an older version and it's not flagged out-of-date. Is there another step to flag the Alpine monero package?
2025-04-11 02:21:09 <mio> jahway603[m]: shows on pkgs.a.o as out of date at my end? https://pkgs.alpinelinux.org/packages?name=monero&branch=edge&repo=&arch=
2025-04-11 02:21:40 <mio> or https://pkgs.alpinelinux.org/flagged?name=monero&branch=edge&repo=&arch=x86_64&maintainer=
2025-04-11 02:22:26 <mio> maybe just needs some time to update
2025-04-11 02:31:09 <jahway603[m]> you may be right as now it's showing out-of-date as expected
2025-04-11 05:49:46 <qaqland> !82621 !82622 !82623 do we have support for 3.17?
2025-04-11 06:43:48 <fabricionaweb> Hi, I may need a merge on this one !82258
2025-04-11 06:53:46 <buinb> Hi
2025-04-11 06:53:55 <buinb> I get a lot of gstreamer errors with webkit2gtk, like:
2025-04-11 06:54:08 <buinb> (WebKitWebProcess:30022): GStreamer-WARNING **: 08:53:34.204: Failed to load plugin '/usr/lib/gstreamer-1.0/libgstjack.so': Error loading shared library /usr/lib/gstreamer-1.0/libgstjack.so: No file descriptors available
2025-04-11 06:54:14 <buinb> That's on amd64
2025-04-11 06:54:55 <buinb> Note that its'n to only about this jack plugin
2025-04-11 06:55:01 <buinb> *it's not
2025-04-11 06:55:24 <buinb> oh
2025-04-11 06:55:40 <buinb> Nevermind, that's webkit2gtk itself borking fd default limits…
2025-04-11 06:56:16 <buinb> It's just up to web quality standards
2025-04-11 08:00:28 <dala_> Hi ! I've been working on enabling the Nouveau vulkan driver in Mesa. However, to be built, it depends on cbindgen which is only available in the community repo. How should I handle this kind of case ? I guess installing it with cargo on the prepare phase is not a solution. Should I fetch its source and build it manually before the build phase ?
2025-04-11 08:56:27 <ncopa> qaqland: we dont really support 3.17 and older anymore. https://alpinelinux.org/releases/
2025-04-11 08:57:02 <ncopa> but I can merge if there are anything critical. not sure how critical this lighthttpd issue is?
2025-04-11 09:40:41 <ncopa> meh... i messed up things again
2025-04-11 11:54:16 <elagost> would someone look at !82590 ? small fix for bash-completion conflicts
2025-04-11 12:44:47 <remexre> is there a good way other than building them oneself to get clang, compiler-rt, lld, etc. for cross-compiling (in particular, to riscv64-alpine-linux-musl)?
2025-04-11 13:28:58 <rhizoome> remexre: probably patch an APKBUILD, it is still building oneself, but with nicer tooling. cross compiling doesn’t really work for a distro, too many problems, so alpine doesn’t need it.
2025-04-11 13:29:33 <remexre> hm, okay
2025-04-11 13:35:06 <rhizoome> remexre: of course there could be containers or other user built solution out in the wild.
2025-04-11 19:17:44 <realroot[m]> https://gitlab.alpinelinux.org/alpine/aports/-/issues/17075
2025-04-11 19:21:29 <realroot[m]> do I need to build qt6-qtbase with that flag?
2025-04-11 19:21:47 <realroot[m]> -DFEATURE_elf_private_full_version=ON
2025-04-11 19:22:24 <psykose> you have to rebuild qt-creator
2025-04-11 19:23:20 <psykose> everything with qt6-qtbase-private-dev and qtdeclarative-private-dev have to be rebuilt on qt updates, but the latter was missed
2025-04-11 19:24:36 <realroot[m]> do i have to rebuild that too?
2025-04-11 19:24:46 <realroot[m]> qtdeclarative-private-dev
2025-04-11 19:27:06 <psykose> the things using the latter were missed, not it itself
2025-04-11 19:28:46 <realroot[m]> do I need to rebuild only qt-creator then right?
2025-04-11 19:29:01 <ikke> 77 packages depending on qt6-qtdeclarative-private-dev..
2025-04-11 19:31:39 <psykose> most of them are rebuilt cause they're just kde stuff
2025-04-11 19:40:19 <realroot[m]> can somebody maybe trigger the rebuild? not sure if -DFEATURE_elf_private_full_version=ON is needed then
2025-04-11 19:47:29 <psykose> elf_private_full_version=ON would normally prevent the broken application from starting (since it would link to somesymbol@qt_6.9.0 and then on qt update only somesymbol@qt_6.9.1 exists so it would show an error instead of crashing)
2025-04-11 19:47:39 <psykose> but on musl it doesn't do anything since musl just loads the latest version
2025-04-11 19:48:58 <psykose> iirc anyway
2025-04-12 07:01:11 <fraolt> I've reviewed !82468 and IMO it is now ready to be merged.
2025-04-12 07:16:56 <ikke> fraolt: I've added you as guest to aports, so you can approve MRs assigned to you 
2025-04-12 07:19:39 <fraolt> Thanks, ikke! Approved.
2025-04-12 08:07:23 <buinb> approved
2025-04-12 15:47:13 <durrendal> https://github.com/luarocks/luarocks-site/issues/220 <- just a heads up for anyone who maintains a lua package that involves luarocks in some way, it appears the site is down due to domain renewal issues.
2025-04-12 22:52:44 <mio> Saijin_Naib[m]: maybe try something like this https://0x0.st/8pEm.txt
2025-04-12 22:53:24 <mio> the release tarball doesn't have the Pinta.AddinUtils files, but they are in the git repo
2025-04-12 22:54:13 <mio> haven't tested if it actually runs, but should build at least on x86_64
2025-04-12 23:00:37 <mio> sorry, that was in reply to your comment earlier in #alpine-linux, wrong channel
2025-04-12 23:29:08 <Saijin_Naib[m]> @mio perfect, let me give that a go! Thank you so much! 
2025-04-12 23:46:31 <mio> you're welcome, good luck!
2025-04-13 05:39:28 <Saijin_Naib[m]> 
ACTION uploaded an image: (360KiB) < https://matrix.org/oftc/media/v1/media/download/AW65dQ2TAkUTObG62r61vNwHCcQRnGQdxqENdlfnBdhnj4C6-fqbzVVgQwPX8hlfdZ0BCkFmg9Dy86VvfsIWRqFCeWdcH3ZQAG1hdHJpeC5vcmcvZ2tNTndxVlZWVkFCeFlyY0VxTFhMalpk >

2025-04-13 05:39:34 <Saijin_Naib[m]> mio you are awesome
2025-04-13 05:39:47 <Saijin_Naib[m]> This release is absolutely incredible. I can't wait for other folks to get to use it too
2025-04-13 05:40:31 <Saijin_Naib[m]> A few exceptions here and there, and plugins don't work, but it seems to work fine for loading/filtering/adjusting/rendering/saving, despite the occasional error popup
2025-04-13 05:40:34 <Saijin_Naib[m]> No crashes/closes
2025-04-13 05:40:55 <Saijin_Naib[m]> Make note of that in the PR? There is no maintainer, so I am not sure who gets to decide if it is ready...
2025-04-13 05:41:09 <Saijin_Naib[m]> Sorry, add-ins that get downloaded from the add-in manager
2025-04-13 05:52:39 <Saijin_Naib[m]> Exceptions are just from the plugins being downloaded/enabled but not working, removing them has it work perfectly
2025-04-13 11:25:19 <kaathewise> Good day!  I wanted to bump the Nushell MR (!81635) again if anyone with merge priviliges has the time to review it
2025-04-13 12:23:48 <kaathewise> Oh, never mind, apparently something broke over the past two weeks
2025-04-13 13:56:51 <timlegge> CVE-2024-56406: Perl 5.34, 5.36, 5.38 and 5.40 are vulnerable to a heap buffer overflow when transliterating non-ASCII bytes
2025-04-13 13:56:54 <timlegge> https://lists.security.metacpan.org/cve-announce/msg/28708725/
2025-04-14 06:48:27 <lotheac> omni: thanks for the PR merges over the weekend :)
2025-04-14 10:02:50 <staceee> how can I launch pipewire when gdm start gnome?
2025-04-14 10:25:34 <staceee> well nothing, I guess gnome start it
2025-04-14 10:39:31 <qaqland> !82681 don't know if it is valid to add depends like this
2025-04-14 12:15:37 <elagost> would someone be able to look at bash-completions mr? Just getting rid of some more conflicts. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/82590
2025-04-14 13:28:25 <fabricionaweb> trying to clone the aports repo - I got a new setup here - but it stuck in clone, is it normal?
2025-04-14 13:29:25 <elagost> fabricionaweb: it might just take a long time, it'a huge repo
2025-04-14 13:29:53 <fabricionaweb> yeah, I thought so, lets see
2025-04-14 18:16:25 <realroot[m]> waht's the process to get qt-creator in stable?
2025-04-14 18:23:55 <f_> realroot[m]: try to get it to community/main
2025-04-14 18:42:28 <rhizoome> making a merge request that moves it to community, then it either goes thru or you learn what it takes.
2025-04-14 18:46:46 <f_> I recommend speaking to the maintainer(s) first
2025-04-14 18:49:35 <realroot[m]> should I ping it here?
2025-04-14 18:51:36 <rhizoome> realroot[m]: that maintainer is rather busy, maybe you open a ticket. so he can deal with it when he has time.
2025-04-14 18:51:45 <rhizoome> issue
2025-04-14 18:53:51 <realroot[m]> i see thanks
2025-04-14 21:58:25 <ptrc> i wish we had a list of maintainers that are completely inactive
2025-04-14 21:58:49 <ptrc> because we have merge requests pending for months, but this kind of stuff usually just gets skipped because "waiting for maintainer"
2025-04-14 22:00:49 <omni> yes, it's often a bit of an investigation plus guess work
2025-04-14 22:01:59 <omni> git log plus gitlab.a.o activity
2025-04-14 22:02:25 <omni> sometimes I do a bit of web search to find out if they're active and could be reached elsewhere
2025-04-14 22:03:01 <fossdd[m]> i made the experience that contacting via email works often
2025-04-14 22:28:49 <omni> is !82561 !82581 another case of having to restart sshd? I haven't tested
2025-04-14 22:56:38 <mio> yes, or might get locked out
2025-04-15 00:25:06 <durrendal> omni: can confirm I locked myself out of one of my servers after failing to restart sshd after the update. 
2025-04-15 07:04:25 <fossdd[m]> i think because they splitted yet another bianry
2025-04-15 07:07:27 <buinb> 
ACTION splits fossdd[m] into IRC and Matrix

2025-04-15 07:09:43 <Saijin_Naib[m]> Is mold drop=in for abuild, and does it significantly speed up builds/linking?
2025-04-15 07:09:58 <Saijin_Naib[m]> I have been trying to build rawtherapee 5.11 and it has been stuck on linking for like, 30min now
2025-04-15 07:12:58 <buinb> Well, appparently it doesn't always :)
2025-04-15 07:14:45 <buinb> “If you find that mold is not faster than other linkers, feel free to [file a bug report](https://github.com/rui314/mold/issues).”
2025-04-15 07:17:40 <buinb> Maybe it got tariffed though (https://pypi.org/project/tariff/1.0.0/)
2025-04-15 07:18:05 <Saijin_Naib[m]> Hmm 🤔 i'll try it
2025-04-15 07:36:54 <Saijin_Naib[m]> Apparently not as easy as simply adding mold to makedepends
2025-04-15 07:37:10 <Saijin_Naib[m]> Ah well, it finally linked and rawtherapee 5.11 works, so I'm submitting the MR now
2025-04-15 07:37:15 <Saijin_Naib[m]> Almost a year out of date!
2025-04-15 07:37:54 <Saijin_Naib[m]> !82812
2025-04-15 07:38:39 <Saijin_Naib[m]> Pinta 3.0 is also ready for review/merge !82725
2025-04-15 07:45:30 <buinb> Saijin_Naib[m], gg :)
2025-04-15 13:50:18 <WhyNotHugo> what should I use in licence= for the following: https://github.com/thestk/rtaudio/blob/master/LICENSE
2025-04-15 13:50:23 <WhyNotHugo> it's an MIT with an extra non-binding clause
2025-04-15 14:12:32 <quinq> It's a custom license, nice :D
2025-04-15 14:14:02 <quinq> WhyNotHugo, I suppose you'll have to create a new SPDX identifier
2025-04-15 14:14:15 <WhyNotHugo> yeah, it's custom
2025-04-15 14:14:23 <quinq> Though the man-page is a bit ambigious
2025-04-15 14:14:28 <WhyNotHugo> and the extra clause is non-binding, so it's functionally equivalent to MIT
2025-04-15 14:14:28 <quinq> “The value provided must match a SPDX license identifier.”
2025-04-15 14:14:52 <quinq> match as in an approved one, or match as in respecting the format?
2025-04-15 14:16:17 <WhyNotHugo> there's an spdx syntax for custom licences, but i can never find this online :(
2025-04-15 14:21:57 <ikke> LicenseRef-$foo
2025-04-15 14:22:11 <ikke> But the linter will not accept it 
2025-04-15 14:24:24 <quinq> WhyNotHugo, can't make a package for that software until you have their custom license added to the official list of SPDX-supported licenses
2025-04-15 14:32:15 <psykose> there's no requirement for that so that statement is false
2025-04-15 14:36:13 <quinq> Maybe you can help instead, then
2025-04-15 14:38:41 <psykose> help with what
2025-04-15 14:39:14 <quinq> Help WhyNotHugo with dealing with the license in the package, what the conversation is about
2025-04-15 14:39:41 <WhyNotHugo> quinq: there's over a hundread packages with license="custom", but APKBUILD still warns that it's invalid.
2025-04-15 14:39:46 <psykose> license=whatever options=!spdx
2025-04-15 14:42:29 <quinq> Thanks
2025-04-15 14:53:12 <ikke> Doesn't mean that's automatically acceptable 
2025-04-15 14:55:38 <mzh> I wrote a license lint parser once, https://gitlab.alpinelinux.org/alpine/infra/atools-go/-/merge_requests/55 , but got rejected.
2025-04-15 14:56:38 <mzh> It's complicated than some simple text if u dig deeper
2025-04-15 14:58:22 <ikke> That was about detecting if a MIT (or similar style) licensed package includes the license 
2025-04-15 14:58:59 <ikke> Which is a hard problem and outside the scope of a static linter 
2025-04-15 19:47:14 <lassebq> Hey. I had a build root based on alpine. Up until some time I had no issue making an upstream kernel from kernel.org. Now there are issues... First is this header missing https://github.com/torvalds/linux/blob/v6.15-rc1/tools/include/linux/kallsyms.h#L21 and after getting libexecinfo from older alpine release, I still ran into error at the end of script: truncate: invalid number '%4K'
2025-04-15 19:53:02 <lassebq> Ok, truncate issue is solved by installing coreutils. But where is libexecinfo? Why is it missing?
2025-04-15 23:27:31 <skarnet> every day Linux is making it harder and harder to build without a full cookie cutter GNU chain of utilities
2025-04-15 23:28:24 <skarnet> last week I had to patch a build because some !@#$%^ script was using "install $target -d" instead of "install -d $target", in a purely gratuitous way
2025-04-15 23:28:42 <skarnet> they just don't care, it's "works on my machine"
2025-04-15 23:30:15 <skarnet> building a kernel on a musl systems already requires jumping through a lot of hoops, as soon as you want objtool you need elfutils, which is hell to build on musl systems
2025-04-15 23:30:44 <skarnet> so I'm not surprised that more and more stuff pulls in gnuisms like execinfo
2025-04-15 23:30:47 <lotheac> i wouldn't go as far as to say they don't care, it's just easy to miss that kind of stuff if you don't automatically test on everything... which is not so easy
2025-04-15 23:31:04 <skarnet> this is the definition of not caring
2025-04-15 23:31:16 <skarnet> in 2025 you don't accidentally miss musl
2025-04-15 23:32:33 <lotheac> i mean yeah i would assume they'd automatically test musl, but i don't think the kernel ci systems are the most sophisticated in the world unfortunately
2025-04-15 23:33:14 <lotheac> but also... there's so many config options it's a bit hard to test the entire matrix
2025-04-15 23:33:52 <skarnet> given the place of Linux today, maybe the kernel CI systems *should* be the most sophisticated in the world?
2025-04-15 23:34:07 <lotheac> i'll grant you that :)
2025-04-15 23:34:35 <lotheac> but i'm not surprised they aren't. developers generally don't want to work on ci
2025-04-15 23:34:46 <lotheac> (in my experience)
2025-04-15 23:34:50 <skarnet> can't blame them tbh
2025-04-15 23:35:16 <p_6f3Ik7Suw> coding in yaml is not fun
2025-04-15 23:43:49 <lotheac> i know, i pretty much do various types of yaml for a living :p
2025-04-16 01:53:31 <Saijin_Naib[m]> https://gitlab.alpinelinux.org/alpine/aports/-/commits/master/community/libjxl/APKBUILD
2025-04-16 01:53:38 <Saijin_Naib[m]> This keeps HTTP 500ing on me
2025-04-16 01:53:55 <Saijin_Naib[m]> Anyone know off-hand when the note was added to disable s390x on libjxl due to CI flakiness?
2025-04-16 01:54:16 <Saijin_Naib[m]> I would like to enable s390x build target for RawTherapee 5.11 with jxl support, but I need libjxl enabled for s390x first
2025-04-16 01:54:34 <Saijin_Naib[m]> But without knowing the history of this issue, I am not sure if I am making the right decision or not
2025-04-16 01:55:34 <mio> https://git.alpinelinux.org/aports/commit/community/libjxl?id=f07062aa15693cce094a18bc217836d1841751d5
2025-04-16 02:00:35 <Saijin_Naib[m]> ALright, that is ammending an older comment
2025-04-16 02:00:40 <Saijin_Naib[m]> So it has been flaky for a while now?
2025-04-16 02:01:17 <mio> https://git.alpinelinux.org/aports/commit/community/libjxl?id=7484255864c1f846f6765376a652e5432ae5f97d
2025-04-16 02:01:40 <mio> since 2024-04
2025-04-16 02:01:53 <mio> s/2024/2023/
2025-04-16 02:01:54 <Saijin_Naib[m]> Is the right solution a platform-specific makedepends condition to drop libjxl-dev for s390x only?
2025-04-16 02:02:06 <Saijin_Naib[m]> And, is there an example of how that is handled in another aport I can look at?
2025-04-16 02:02:33 <Saijin_Naib[m]> Ah, crap. Two years broken... Alright, I think this is a windmill I need not tilt, then
2025-04-16 02:03:54 <mio> depends if it still builds/functions without the lib
2025-04-16 02:04:06 <mio> an example might be one of its revdeps, https://git.alpinelinux.org/aports/log/community/wpewebkit
2025-04-16 02:05:49 <mio> sorry, specifically https://git.alpinelinux.org/aports/commit/community/wpewebkit?id=b2d7109cf8565ab49db31bb31e20cae7863bb42a
2025-04-16 02:08:43 <Saijin_Naib[m]> Build notes for this release say libjxl is an optional depdency, so, yeah, it should be fine
2025-04-16 02:09:09 <Saijin_Naib[m]> Build process is set to, by default, enable jxl support only if it is found with cmake, or disable if not found
2025-04-16 02:09:39 <Saijin_Naib[m]> You can force it one way or another with the -Dwhatever options, but I am not changing that, so it should(TM) behave
2025-04-16 02:16:16 <Saijin_Naib[m]> hmmm
2025-04-16 02:16:58 <Saijin_Naib[m]> would I do a CASE "$CARCH" NOT IN s390x) to add it in for everything else like the above example?
2025-04-16 02:17:12 <Saijin_Naib[m]> Or, is there a way to drop it from the listed makedepends?
2025-04-16 02:17:21 <Saijin_Naib[m]> Sorry, I am not great at understanding bash at all
2025-04-16 02:30:18 <mio> have a look at the wpewebkit APKBUILD again, around L65
2025-04-16 02:31:51 <mio> there's a case statement with two arches that don't have the lld makedepends, and the others where it's appended to the variable
2025-04-16 02:32:41 <mio> something like that
2025-04-16 05:00:26 <systemdlete> I started posting by accident over in alpine-linux.  I just successfully made and installed the packages for virtualbox guest additions 7.1.8
2025-04-16 05:02:45 <systemdlete> sorry, meant 7.1.6, and I am in the process of porting it to 7.1.8, which was just made available at virtualbox.org in the past few hours or so.
2025-04-16 05:03:35 <systemdlete> The 7.1.6 seems stable enough, although the clipboard still doesn't seem to talk to the host and v.v.  But that has been a problem for some time now on alpine version of the GAs.  
2025-04-16 05:03:43 <systemdlete> (I might take a look at it though)
2025-04-16 05:04:33 <systemdlete> I just want to mention that I hope I have not stepped on any toes; I know there are at least a couple people who have been maintaining the vbox GAs.  I meant to be helpful not get out of lilne.
2025-04-16 05:04:37 <systemdlete> line.
2025-04-16 05:05:52 <ikke> You are aware of this, right? https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/virtualbox-guest-additions/APKBUILD
2025-04-16 05:05:58 <systemdlete> What is the protocol (if any) for pushing or creating a pull reqest
2025-04-16 05:06:03 <systemdlete> ikke: thanks
2025-04-16 05:06:39 <ikke> Fork aports, commit your changes to a branch, push it to your fork, make a merge request
2025-04-16 05:06:53 <systemdlete> ah, thank you!
2025-04-16 05:07:06 <systemdlete> and, yes, that is where I got the APKBUILD stuff and all
2025-04-16 05:07:21 <systemdlete> (though tbh, I downloaded a tar, not git)
2025-04-16 05:08:05 <systemdlete> ikke: To avoid duplicate work, is there a way to sort of communicate with others who might also be working on the same package?
2025-04-16 05:08:51 <systemdlete> One project had a board where people were supposed to post what they were doing (although some people did not care to keep it updated).
2025-04-16 05:09:30 <ikke> We don't have anything dedicated for that
2025-04-16 11:50:10 <raspbeguy> can someone review the following PR please? thank you. !78885 !81429 !81327 !82823 !78807 !74517 !72559
2025-04-16 11:51:08 <raspbeguy> I just marked tempo PR as ready
2025-04-16 20:35:30 <systemdlete> ikke (or whoever might answer): I created fork on gitlab, made my changes locally, I get an error saying I don't have permission to push to this project.
2025-04-16 20:35:56 <ikke> systemdlete: make sure you push to your fork, not to the alpine/aports
2025-04-16 20:36:02 <systemdlete> ah
2025-04-16 20:36:04 <ikke> You may need to add it as a separate remote
2025-04-16 20:36:12 <systemdlete> ok
2025-04-16 20:46:33 <systemdlete> done.  (I thimk... )
2025-04-16 20:47:04 <systemdlete> it was surprisingly easier than I had anticipated.  I'm not very good at git
2025-04-16 20:47:16 <systemdlete> (I just don't git et!)
2025-04-16 20:47:27 <systemdlete> but gitlab did make things a bit easier.
2025-04-16 20:48:51 <systemdlete> hmmm.  I only see one file on gitlab...
2025-04-16 20:53:17 <systemdlete> ikke:  I think I screwed something up.
2025-04-16 20:53:34 <ikke> Do you have a link?
2025-04-16 20:54:17 <systemdlete> when I committed, I just ran git commit.  I figured all my changes were in.
2025-04-16 20:54:39 <ikke> systemdlete: what does git status say?
2025-04-16 20:55:21 <systemdlete> oh what fun this is.
2025-04-16 20:55:36 <systemdlete> I meant to have a branch virtualbox-guest-additions-7.1.8
2025-04-16 20:55:59 <systemdlete> now I also have a branch  virtualbox-guest-additions-7.1.8/virtualbox-guest-additions-7.1.8
2025-04-16 20:56:02 <systemdlete> !!!
2025-04-16 20:56:27 <systemdlete> I think the problem was that I was using an option to specify the remote as well as having set it
2025-04-16 20:56:38 <systemdlete> something like that.  Again, not very good at git
2025-04-16 20:58:05 <systemdlete> something ALWAYS goes wrong when I use git.
2025-04-16 21:03:51 <systemdlete> Here is what I see on my local system:  https://dpaste.com/2VUYLPGR9
2025-04-16 21:05:15 <systemdlete> ikke: I hope dpaste is ok with you (some folks have paste prefs)
2025-04-16 21:08:39 <ikke> it's fine
2025-04-16 21:08:52 <systemdlete> Now gitlab IS showing my other change... but I have 2 separate commits
2025-04-16 21:10:23 <systemdlete> (or is it, let's see...)
2025-04-16 21:11:04 <systemdlete> See, I made changes to APKBUILD also.  But I am not seeing it with the other (a new) file I created.
2025-04-16 21:11:26 <systemdlete> Latency on gitlab maybe?  idk
2025-04-16 21:46:52 <systemdlete> ikke: There should have been a total of 3 changes:  APKBUILD (of course), mod to one of the patches, and a new patch.  I only see the new patch file in the MR
2025-04-16 22:31:51 <systemdlete> ikke:  I typo'd.  I left out a letter in the branch name
2025-04-16 22:33:08 <systemdlete> I closed the MR until I can figure this out
2025-04-16 23:06:52 <systemdlete> ikke:  I blew the (bad) branch away (on both local and remote/gitlab) and started over
2025-04-16 23:07:31 <systemdlete> I forgot to add those two files to the commit!  
2025-04-16 23:07:49 <systemdlete> Anyway, I've made my changes locally (again), committed, and pushed.
2025-04-16 23:16:03 <systemdlete> I just created the MR and I can see all 3 of the files involved on gitlab.  So, I think(?) I've done it correctly this time.
2025-04-16 23:58:01 <systemdlete> So my changes passed, except for x86.  
2025-04-17 01:35:26 <systemdlete> Is it likely that gitlab is somewhat latent?  I notice that my changes (push, canceled jobs, etc) take some time to be reflected on the web site.
2025-04-17 02:33:00 <systemdlete> why is it that, on 3.21.3, the sudoers file is different on 32bit vs 64bit default installs?
2025-04-17 02:33:21 <systemdlete> I have not made any changes to the sudoers file(s) on either, afaicr
2025-04-17 02:33:40 <systemdlete> def not the 32 bit version, because I just installed it about an hour ago!
2025-04-17 02:34:17 <systemdlete> the 64 bit version allows me to "sudo bash" from a regular user.  The 32 bit version does not--complains regular user is not in the sudoers file.
2025-04-17 02:35:46 <systemdlete> I checked apk policy on both and the sudo version is the same (1.9.16_p2-r0)
2025-04-17 02:36:44 <systemdlete> sudo should not be allowing me to "sudo bash" into superuser, according to the docs, yet it does.
2025-04-17 02:37:17 <systemdlete> and the regular user is not a member of group "sudo" "wheel" or anything else that would give it su power)
2025-04-17 02:47:39 <systemdlete> I did read the output of the diff wrong.  nvm.  The files really are different, but as long as it is working, ok.  I just had to allow the ALL ALL=... line 
2025-04-17 04:29:11 <Saijin_Naib[m]> Can I get a review/merge for !82812 and !82725
2025-04-17 04:29:47 <Saijin_Naib[m]> RawTherapee 5.12 is coming in a few days and 5.11 is already a year old and not releassed in Alpine, haha
2025-04-17 06:38:07 <systemdlete> x86 version of virtualbox-guest-additions built on my 32 bit alpine linux install.  But it failed in the pipeline.  I'm new with git and gitlab, so please be patient as I stumble... err, I mean as I learn all of this.
2025-04-17 06:38:34 <systemdlete> I looked at the pipeline job and it looked like a build fail, but I'm not getting that on my 32 bit alpine.
2025-04-17 06:39:30 <systemdlete> alpine 3.21.3 virtual image under virtualbox 7.1.6
2025-04-17 06:39:59 <systemdlete> can I re-submit it some way, or do I need to create a new MR?
2025-04-17 06:40:45 <ikke> Amend the commit, force push 
2025-04-17 06:41:01 <ikke> systemdlete: textrels can be complicated 
2025-04-17 06:41:18 <systemdlete> oh, I just noticed that it passed
2025-04-17 06:41:24 <systemdlete> or
2025-04-17 06:41:26 <systemdlete> no
2025-04-17 06:41:33 <systemdlete> that's for the x86_64 build
2025-04-17 06:41:52 <systemdlete> so just amend, like, anything at all?
2025-04-17 06:42:00 <systemdlete> (add a space to the comment?)
2025-04-17 06:44:28 <ikke> What do you want to resubmit?
2025-04-17 06:45:22 <systemdlete> that's what I'm asking, I am not sure.  I can successfully compile the package on my own local x86, but it failed in the pipeline.
2025-04-17 06:45:50 <systemdlete> so, I am wondering if re-submitting that build to the pipeline again is possible?
2025-04-17 06:47:58 <systemdlete> btw, ikke, I am re-running the same abuild here on my x86 alpine vm, just to double check.
2025-04-17 06:53:49 <systemdlete> crud.  this time it failed.
2025-04-17 08:03:39 <PureTryOut> Hmm for some reason after installing the package deps abuild rootbld just hangs forever and never actually builds anything
2025-04-17 08:09:53 <ncopa> its possible it hangs when calculating the deps?
2025-04-17 08:10:15 <ncopa> Im setting pu the 3.22 builders today
2025-04-17 08:10:25 <PureTryOut> It already installed all the deps though 🤔
2025-04-17 08:11:01 <ncopa> anything related toolschains or abuild or anything that should be done before we get buildesr up?
2025-04-17 08:11:08 <ncopa> maybe update linux-headers?
2025-04-17 10:23:52 <ikke> Is it https://gitlab.alpinelinux.org/alpine/abuild/-/commit/c5b0b6a60bd385721231dedde29e8a82b0f4ac24?
2025-04-17 10:39:19 <ncopa> what is this about? https://build.alpinelinux.org/buildlogs/build-edge-aarch64/testing/firefox-developer-edition/firefox-developer-edition-138.0_beta7-r0.log
2025-04-17 10:39:31 <ptrc> the world on aarch64 has some broken python deps
2025-04-17 10:39:41 <ptrc> but even if this is fixed, it needs some fixes to build with llvm20
2025-04-17 10:39:45 <ptrc> working on it right now
2025-04-17 10:47:01 <fossdd[m]> <ncopa> "what is this about? https://..." <- this is https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/82902
2025-04-17 10:50:28 <ncopa> aha
2025-04-17 10:50:33 <ncopa> thanks for working on it
2025-04-17 10:58:50 <ptrc> ooh, that's a different error than the one i've been working on, hah
2025-04-17 18:16:21 <craftyguy[m]> would the aports pre-merge CI benefit from a test that checks when a library package is bumped in a branch, identifies all rdepends on it that should also be rebuilt against it, and fails if those rdepends aren't also pkgrel bumped in the same branch?
2025-04-17 18:16:25 <craftyguy[m]> I'm wondering if this would help with some of the breakage on edge lately, where some things were not rebuilt when e.g. icu was upgraded
2025-04-17 18:16:59 <craftyguy[m]> at least then we could block the MR until the check passes (indicating that all things in aports that should be rebuilt are included in the branch)
2025-04-17 18:25:20 <Habbie> only if the soname is bumped, right?
2025-04-17 18:29:39 <quinq> craftyguy[m], sounds like a good idea
2025-04-17 18:30:43 <craftyguy[m]> ya only soname, not all depends
2025-04-17 18:30:46 <quinq> Maybe not blocking, but at least warned
2025-04-17 18:31:17 <craftyguy[m]> why not blocking?
2025-04-17 18:31:36 <quinq> Because of what Habbie said
2025-04-17 18:31:37 <sertonix[m]> craftyguy: The icu upgrade was intentionally merged without fixing all rdepends since it was too complicated to fix them all at the same time. That's why blocking is an issue
2025-04-17 18:31:47 <craftyguy[m]> ahhh ok
2025-04-17 18:42:41 <psykose> a nice change would be to not upload each repo individually and only do it after all 3 are done
2025-04-17 18:44:53 <craftyguy[m]> yeah, that sounds harder to implement than a CI check
2025-04-17 18:45:11 <craftyguy[m]> but ya, what you suggested would be really nice
2025-04-17 18:50:36 <psykose> it's just moving around the upload in https://img.ayaya.dev/ADCb7emBMOZI from at the end of each repo loop to outside it, more or less
2025-04-17 18:51:05 <psykose> i suggested it years ago but the idea was that 'it would mean something failing in testing would block an upload and some people might be upset some other update didnt get uploaded faster'
2025-04-17 18:51:11 <psykose> i.e. trading consistency for sometimes it being faster
2025-04-17 18:51:50 <psykose> so now every single major icu/whatever upgrade you have like 50 people asking why half the packages can't be installed and are broken on edge
2025-04-17 18:52:23 <craftyguy[m]> it is worth bringing that back up for discussion? seems like we have new data :P
2025-04-17 18:52:36 <psykose> it's not new data at all i don't think
2025-04-17 18:53:23 <craftyguy[m]> well, I just mean that lots of folks are complaining, maybe more than before? I'm guessing
2025-04-17 18:53:44 <psykose> i can't say i've seen more complaints, this discussion happens every single icu update
2025-04-17 18:54:14 <psykose> it's separate from the 'intentionally skipped some rebuilds and left broken packages linked to old soname' issue as well
2025-04-17 18:54:30 <psykose> i think the only thing that changed is there's like more packages now
2025-04-17 18:54:54 <psykose> and it takes both more time to fix intentionally-skipped stuff (2nd issue), and more time to actually build everything after main/ has uploaded in the lower repos (1st issue)
2025-04-17 18:54:56 <craftyguy[m]> it's not just icu I've experienced this with in the past (having trouble recalling the others..)
2025-04-17 18:55:08 <psykose> 1st one can be fixed by just delayed the upload to the end with my suggesting, 2nd issue is eh
2025-04-17 18:55:34 <psykose> it happens with more stuff yeah, icu is just the first example i remember
2025-04-17 18:56:33 <psykose> but this has definitely been talked about many times over the years
2025-04-17 18:57:01 <craftyguy[m]> I see. I'm mostly just observing this stuff from the "outside", we get a lot of people looking for help in pmOS when this stuff happens, so I was just trying to think of some way I could help prevent it. It's possible I'm missing a lot of info/context :P
2025-04-17 18:57:43 <craftyguy[m]> (we encourage folks to run stable releases, but ya... sometimes users are gonna ignore us 🙃)
2025-04-17 18:58:05 <psykose> if it was a new distro from scratch the easiest day-one policy decision is to not unstage a repo (i.e. allow new packages to be on mirror) until consistency checks pass (all soname stuff points to actual packages, nothing missing)
2025-04-17 18:58:11 <psykose> to do that now would be pretty controversial
2025-04-17 18:58:14 <psykose> it's not very hard to implement
2025-04-17 18:59:32 <craftyguy[m]> yeah I can imagine...
2025-04-17 18:59:39 <ncopa>   clang (no such package):
2025-04-17 18:59:39 <ncopa>     required by: .makedepends-wasi-libc-20250417.185823[clang]
2025-04-17 18:59:47 <ncopa> i get that error on bootstrapping abuild now
2025-04-17 19:00:24 <psykose> that's weird, the latest repo index has clang pointing to clang20
2025-04-17 19:00:50 <craftyguy[m]> how do you bootstrap abuild? ( I could try to reproduce it)
2025-04-17 19:01:08 <psykose> it sounds like a circular dep and clang hasn't been built yet
2025-04-17 19:01:19 <ncopa> yeah, clang is not built yet
2025-04-17 19:01:34 <ncopa> i build from an empty repo
2025-04-17 19:02:11 <ncopa> only build-base installed (+ a few more) and then I build everything int the dependency chain to abuild
2025-04-17 19:02:36 <ncopa> but i also wonder why we need clang in the chain to build abuil
2025-04-17 19:02:48 <ncopa> re build all repos before upload
2025-04-17 19:02:51 <ncopa> we did that in the past
2025-04-17 19:02:56 <ncopa> but got complaints
2025-04-17 19:03:25 <ncopa> what happened was that some people pushed broken stuff
2025-04-17 19:03:41 <ncopa> which completely blocked any other updates til it was resolved
2025-04-17 19:04:04 <psykose> since it says wasi-libc it's probably rust
2025-04-17 19:04:17 <ncopa> right, that makes sense
2025-04-17 19:04:19 <psykose> and yeah that's fine, it means broken stuff that doesn't build breaks the repo
2025-04-17 19:04:34 <ncopa> we could reconsider introducing it
2025-04-17 19:04:35 <psykose> exactly what i said with 'trading consistency for speed'
2025-04-17 19:04:40 <ncopa> yeah
2025-04-17 19:04:58 <psykose> it needs a small cultural change that people don't leave broken builds hanging around for days
2025-04-17 19:05:09 <ncopa> but i think it will be sort of unpopular, since we relatively often have builders non-idle
2025-04-17 19:05:09 <psykose> one of the issues with that is it's hard sometimes to know it even happens
2025-04-17 19:05:17 <ncopa> yeah
2025-04-17 19:05:17 <psykose> like, works in ci, gets merged, it's broken + nobody sees
2025-04-17 19:05:23 <ncopa> exactly
2025-04-17 19:05:42 <ncopa> and then a few days later, hey where is the package i pushed yesterday?
2025-04-17 19:06:01 <psykose> haha yeah, already happens with blocked repos
2025-04-17 19:06:09 <craftyguy[m]> how do those systems pass CI?
2025-04-17 19:06:11 <ncopa> yup
2025-04-17 19:06:20 <craftyguy[m]> *packages, not systems lol
2025-04-17 19:06:29 <ikke> various reasons
2025-04-17 19:06:31 <psykose> craftyguy[m]: sometimes it's a 'flaky test' that has a 100% fail rate on builder only
2025-04-17 19:07:05 <psykose> most common reason is some other builder issue, like random package left over in world, weird ~/ state the package fails on (the builds are not in a clean env like rootbld or a fresh ci run), etc
2025-04-17 19:07:28 <psykose> the whole architecture is obviously not good, but fixing that specifically is a pretty big project
2025-04-17 19:07:37 <ncopa> build from clean env has higher prio i'd guess
2025-04-17 19:07:44 <craftyguy[m]> I see, yikes. ya I had a recent experience with a pkg failing only on the builder (some zig thing, ikke was involved :P)
2025-04-17 19:08:15 <psykose> basically literally any inconsistency between CI machine setup and real setup comes to bite you eventually
2025-04-17 19:08:35 <psykose> a few times it was 'ci env uses a machine with cpu that has avx2, builder only has avx, package did something weird with cpus like that'
2025-04-17 19:08:37 <psykose> forgot specifics
2025-04-17 19:08:58 <psykose> but the biggest major reason is just that non-ephemeral env
2025-04-17 19:10:09 <psykose> ncopa: maybe you forgot to copy 'old rust' for bootstrap? i think that would cause that order issue
2025-04-17 19:10:40 <ncopa> i suspect it it `ap` that does not get the provides=clang in clang20
2025-04-17 19:10:52 <psykose> clang19 did the same and that worked last release didn't it
2025-04-17 19:10:58 <psykose> but maybe
2025-04-17 19:11:48 <psykose> like the last time main/clang existed was in 15
2025-04-17 19:12:10 <psykose> since then it's been provides=clang only
2025-04-17 19:12:14 <craftyguy[m]> psykose: thank you for explaining. do y'all need help exploring/planning/doing build infra improvements?
2025-04-17 19:12:26 <ncopa> but maybe rust was not in the abuild dep chain back then
2025-04-17 19:12:33 <craftyguy[m]> in pmOS-land, we also have issues with our build system, maybe we can join forces
2025-04-17 19:13:47 <ikke> https://gitlab.alpinelinux.org/alpine/tsc/-/issues/82
2025-04-17 19:13:50 <ncopa> yes, rust-bootstrap is in dep chain
2025-04-17 19:14:25 <craftyguy[m]> haha, Ollie beat me by 6 months
2025-04-17 19:14:28 <psykose> craftyguy[m]: i'm not involved so no idea
2025-04-17 19:18:19 <craftyguy[m]> ikke: anything I could help with on that issue? like do you want to do more evaluation of off-the-shelf stuff or are there other things you're waiting on that maybe I could help with?
2025-04-17 19:21:33 <ncopa> lua-aports is supposed to be able to deal with provides
2025-04-17 19:22:11 <ikke> craftyguy[m]: evaluating existing options would be helpful
2025-04-17 19:23:16 <ncopa> smells like a bug in lua-aports
2025-04-17 19:23:21 <ncopa> will have to deal with it tomorrow
2025-04-17 19:23:24 <ncopa> good night
2025-04-17 19:23:29 <ikke> o/
2025-04-17 19:24:09 <craftyguy[m]> ok, I would be happy to work on that. I could use some help though making sure all of the requirements listed in that issue are still current (and if there's anything else to add/detail). having a solid list of what you require from build infra will make it easier to evaluate options :P
2025-04-17 19:24:26 <craftyguy[m]> maybe psykose could help with that ^^ :D
2025-04-17 19:25:58 <psykose> i know the current state because i studied it for a while, i don't have any say in changing it though
2025-04-17 19:28:43 <craftyguy[m]> ya I know that, maybe you have some opinion on how the current state could be fixed, and maybe you have something to add to that issue above. It's fine if you don't, but I clearly haven't studied it as much as you have (and probably not many here have?), so you might have something useful to say about what the next thing should have/do
2025-04-17 20:04:20 <durrendal> omni: thanks for looking at my MRs, do you mind taking a look at the sbcl upgrade as well? It's ready to go, but it's about a month old at this point so probably not at the top of the stack
2025-04-17 20:15:08 <tmtt> Hi! When porting a new package to aports, is it best to build the package's source code from scratch or to directly download the compiled binaries when provided? I'm trying to package livekit (https://github.com/livekit/livekit) and they already provide static binaries for amd64, arm64 and armv7. thanks in advance :)
2025-04-17 20:15:27 <craftyguy[m]> build from source
2025-04-17 20:15:57 <craftyguy[m]> it's less sketchy, and the prebuilt stuff probably links against glibc and/or other things that will cause problems on alpine
2025-04-17 20:16:45 <tmtt> It's written in go so it's static anyway but yeah building from source is probably the way to go
2025-04-17 20:16:58 <tmtt> I'll do that then
2025-04-17 20:17:00 <tmtt> thanks :)
2025-04-17 20:19:06 <ikke> tmtt: it's our policy to build from source
2025-04-17 21:50:48 <ncopa> wasi-libc does not seem to build with clang20
2025-04-17 21:53:30 <omni> I feel like I shouldn't have merged that chromium security upgrade
2025-04-17 21:55:52 <psykose> does build on master
2025-04-17 22:02:19 <omni> it does?
2025-04-17 22:55:17 <ptrc> wasi-libc is kinda broken in general
2025-04-17 22:55:27 <ptrc> i tried to update all the wasm stuff to llvm20
2025-04-17 22:55:38 <ptrc> ended up giving up for now and building firefox-dev-edition with llvm19
2025-04-17 22:55:54 <fossdd[m]> urgh
2025-04-17 22:56:34 <psykose> what's broken with it
2025-04-17 22:57:29 <ptrc> uhhhhhh forgot already
2025-04-17 22:57:32 <ptrc> lemme check
2025-04-17 22:58:14 <ptrc> ah, missing macro somehow
2025-04-17 22:58:23 <psykose> which one
2025-04-17 22:58:30 <ptrc> https://ptrc.gay/GrzgJwvJ
2025-04-17 22:58:44 <psykose> you can just remove the BULK_=
2025-04-17 22:58:46 <ptrc> that should be set by the makefile
2025-04-17 22:58:59 <psykose> it will fail after on extra symbols
2025-04-17 22:59:01 <psykose> bumping it fixes that
2025-04-17 22:59:27 <ptrc> yeah it does fail on extra symbols\
2025-04-17 22:59:33 <psykose> chimera has patches for clang20 in ff and the rest of the wasi -20 changes, not sure if bumped wasi-libc will work but probably
2025-04-17 23:00:13 <ptrc> bumping it to what version? i assume further than tag wasi-sdk-25 :/
2025-04-17 23:00:56 <fossdd[m]> just latest commit id assume
2025-04-17 23:02:50 <ptrc> hm, yup
2025-04-17 23:02:52 <ptrc> that works
2025-04-17 23:03:34 <psykose> it's already not -25
2025-04-17 23:03:45 <psykose> (older)
2025-04-17 23:03:49 <ptrc> ah
2025-04-17 23:04:01 <ptrc> latest wasi-libc is still not enough for wasi-compiler-rt somehow..
2025-04-17 23:04:12 <ptrc> https://ptrc.gay/GNdlLXdn
2025-04-17 23:05:00 <psykose> see https://github.com/chimera-linux/cports/commit/31ceb88341674dffeecdb6cbca684f9bccf4b009 for rest of changes
2025-04-17 23:05:06 <psykose> that looks like the disabled profiling
2025-04-17 23:06:31 <ptrc> hmmm
2025-04-17 23:06:55 <ptrc> the missing header does sound like something's broken though
2025-04-17 23:07:07 <ptrc> ah
2025-04-17 23:07:11 <ptrc> it works just fine with wasi-sdk
2025-04-17 23:07:17 <ptrc> but that's a circular dep
2025-04-17 23:07:20 <ptrc> bleh
2025-04-17 23:07:36 <ptrc> ( it needs the clang configs to pick up the sysroot properly )
2025-04-17 23:08:04 <psykose> sysroot is just a path
2025-04-17 23:08:10 <psykose> the failed cc has no sysroot
2025-04-17 23:08:21 <ptrc> yeah
2025-04-17 23:09:02 <ptrc> someone tried to make it work by adding the --sysroot into CFLAGS but that gets ignored
2025-04-17 23:09:41 <psykose> mythical someone
2025-04-17 23:09:45 <psykose> someplace sometime
2025-04-17 23:09:56 <ptrc> yes hi someone :3
2025-04-17 23:10:11 <systemdlete> Is the rule that ALL platforms must pass the pipeline in order to merge it into master?  Or are exceptions ever made for x86?
2025-04-17 23:10:31 <fossdd[m]> all should pass
2025-04-17 23:10:31 <ptrc> i mean, you can just disable platforms if they don't work
2025-04-17 23:10:44 <ptrc> but in general broken pipelines are a no-go for merging
2025-04-17 23:10:44 <psykose> disabling them makes them pass
2025-04-17 23:10:48 <ptrc> fair.
2025-04-17 23:10:49 <psykose> broken ci is a fail generally
2025-04-17 23:11:08 <systemdlete> so... I need to find a way to make it work?
2025-04-17 23:11:17 <ptrc> what's the context here
2025-04-17 23:11:32 <systemdlete> virtualbox-guest-additions for 7.1.8
2025-04-17 23:11:42 <psykose> arch="all !x86"
2025-04-17 23:11:44 <systemdlete> on alpine x32
2025-04-17 23:11:51 <systemdlete> psykose, ok
2025-04-17 23:12:34 <psykose> x86 is not x32
2025-04-17 23:12:53 <ptrc> i mean
2025-04-17 23:12:53 <fossdd[m]> sweet 98% of llvm tests and my system stops responding
2025-04-17 23:13:04 <fossdd[m]> i wish ive setup swap
2025-04-17 23:13:07 <ptrc> here it's only x86 and x86_64, so just remove x86 i guess?
2025-04-17 23:13:22 <psykose> yeah, x86_64 only
2025-04-17 23:14:08 <systemdlete> x86 is not 32 bit?  sorry, I thought that was the meaning of it.
2025-04-17 23:14:24 <ptrc> "x32" != 32-bit
2025-04-17 23:14:27 <fossdd[m]> x86 is 32bit and x86_64 is 64bit
2025-04-17 23:14:56 <systemdlete> 
ACTION senses some disagreement in the channel...

2025-04-17 23:15:32 <systemdlete> I thought x86 meant 32 bit registers and x86_64 meant 64 bit registers.  No?
2025-04-17 23:16:30 <psykose> x32 is x86_64 with ilp32
2025-04-17 23:16:50 <psykose> and is cursed and pretty much nobody supports it
2025-04-17 23:16:59 <psykose> x86 is the ye old x86
2025-04-17 23:17:20 <systemdlete> so I used the wrong term
2025-04-17 23:17:39 <systemdlete> when I said x32 I just meant the x86 architecture
2025-04-17 23:17:45 <systemdlete> (vs 64 bit)
2025-04-17 23:18:02 <ptrc> correct
2025-04-17 23:18:18 <sertonix[m]> ncopa: recursive-deps of git includes rust-bootstrap and git is a checkdepends of abuild. We should teach lua-aports to ignore checkdepends when wanted
2025-04-17 23:18:19 <systemdlete> btw, "ye" is pronounced "the" just as in modern English.
2025-04-17 23:18:36 <systemdlete> (the "y" actually is thorn, a now disused letter of the alphabet)
2025-04-17 23:18:51 <systemdlete> so "the ye" is redundant
2025-04-17 23:19:06 <systemdlete> (since we seem to be haggling over minutia)
2025-04-17 23:20:13 <systemdlete> would all agree to exclude x86 from the APKBUILD arch= line?  I mean, is that kosher here?
2025-04-17 23:20:47 <ptrc> you can also try and find where the textrels occur
2025-04-17 23:20:55 <ptrc> and possibly fix it in a downstream patch
2025-04-17 23:21:00 <systemdlete> ptrc, I can clearly see where they are.
2025-04-17 23:21:07 <ptrc> can you see which function?
2025-04-17 23:21:13 <systemdlete> downstream?  don't you mean upstream?
2025-04-17 23:21:30 <systemdlete> I think these changes would need some examination by the vbox devs
2025-04-17 23:21:32 <ptrc> no, i mean downstream, a patch in aports rather than submitted upstream
2025-04-17 23:21:36 <ptrc> we already have plenty of those
2025-04-17 23:21:52 <systemdlete> well, I think it is worth alerting them anyway, right?
2025-04-17 23:21:58 <systemdlete> there could be other issues lurking.
2025-04-17 23:22:05 <ptrc> if you want to, sure
2025-04-17 23:22:31 <systemdlete> for now, I will exclude x86 from the arch line.  (For some reason, though, this seems to have worked in the past...)
2025-04-17 23:22:41 <sertonix[m]> ncopa: if you set APORTS_BOOTSTRAP=1 git has less rmakedepends which doesn't include rust-bootstrap anymore
2025-04-17 23:22:44 <systemdlete> (confluence of changes I guess)
2025-04-17 23:23:13 <systemdlete> Now, as far as gitlab, do I need a new MR or should I amend the MR, or how does that work?
2025-04-17 23:23:46 <systemdlete> 
ACTION is a newbie with git and gitlab/github

2025-04-17 23:23:54 <ptrc> amend the commit, force-push
2025-04-17 23:24:26 <systemdlete> what happens to the current MR?  Will it just be discarded or disregarded?
2025-04-17 23:24:41 <fossdd[m]> it will be updated with your new commit
2025-04-17 23:24:44 <ptrc> MR is tied to the branch
2025-04-17 23:24:50 <ptrc> so if you force-push to the branch, it updates the MR
2025-04-17 23:24:51 <systemdlete> and, thanks to all for the help.
2025-04-17 23:24:56 <systemdlete> ah, ok.
2025-04-17 23:25:02 <systemdlete> that's exactly what I wanted to know
2025-04-17 23:25:08 <systemdlete> makes sense too
2025-04-17 23:25:21 <systemdlete> thank you so much for your patience as I learn all of this.
2025-04-17 23:25:41 <systemdlete> Maybe if I get really good at this, I can become a more regular contributor
2025-04-17 23:26:22 <systemdlete> so your help matters... if you need more contributors like me
2025-04-17 23:28:33 <systemdlete> atm, the APKBUILD has arch="x86 x86_64" not arch="all"
2025-04-17 23:28:49 <systemdlete> yet the pipeline built for numerous platforms... and passed?
2025-04-17 23:29:02 <systemdlete> (I did not look at the job output for those others)
2025-04-17 23:29:16 <ptrc> when you specify architectures explicitly, only those architectures are enabled
2025-04-17 23:29:26 <ptrc> so everything else is just skipped = passed
2025-04-17 23:29:26 <systemdlete> that's what I figured
2025-04-17 23:29:30 <systemdlete> ah
2025-04-17 23:29:31 <systemdlete> ok
2025-04-17 23:29:49 <systemdlete> btw, what is the exact meaning of "skipped" -- that's what the MR is saying now
2025-04-17 23:29:59 <ptrc> there's two kinds of skipped
2025-04-17 23:30:20 <ptrc> there's GitLab skipped, when you rebase a MR without re-running CI, or push with `-o ci.skip`
2025-04-17 23:30:38 <ptrc> and there's "skipped" as in, the CI job for a given architecture does nothing
2025-04-17 23:30:46 <ptrc> it still runs though, it just doesn't build the package
2025-04-17 23:31:33 <systemdlete> two kinds, which is what I suspected.  Thank you for clarification and confirmation
2025-04-17 23:32:10 <systemdlete> ok, I am making the change and pushing it now...
2025-04-17 23:33:41 <systemdlete> now, in the case of vbox, I'd think that arch="x86_64" since vbox is not supported outside of the x86* family
2025-04-17 23:33:48 <ptrc> yeah, that makes sense
2025-04-17 23:33:53 <systemdlete> ok
2025-04-17 23:34:05 <ptrc> also, apparently Ermine figured it out 6 months ago already, but nobody answered the comment: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/71859#note_439255
2025-04-17 23:34:43 <ptrc> ( i got to the same conclusion, and a google search for "VBoxClient lazyload textrels" gave me the Alpine MR... )
2025-04-17 23:35:09 <ptrc> https://bugs.gentoo.org/947998
2025-04-17 23:35:31 <ptrc> Gentoo just went "patches welcome" - which is very valid here, this entire layer of metaprogramming seems a bit annoying
2025-04-17 23:36:47 <ptrc> though funnily enough, the textrels happen only for gtk3 and x11, not for any other library
2025-04-17 23:39:27 <systemdlete> yes, that is exactly where I found those textrels
2025-04-17 23:41:08 <systemdlete> I will try to get hold of the vbox devs; I've worked with them in the past on vbox issues (including past attempts to build their "open source")
2025-04-17 23:41:43 <systemdlete> maybe they can come up with a better support paradigm for this.
2025-04-17 23:42:08 <systemdlete> IOW, maybe they should fix their own code to be more portable, etc
2025-04-17 23:42:40 <Ermine> I've contacted them
2025-04-17 23:42:43 <systemdlete> rather than to "patch the whole lazy-loading thing out" as Ermine suggest
2025-04-17 23:42:50 <systemdlete> oh, ok
2025-04-17 23:42:55 <systemdlete> what did they tell you?
2025-04-17 23:43:32 <Ermine> they generate some assembly to lazily load dynamic libraries
2025-04-17 23:43:52 <systemdlete> also, do you want to take this over?  I mean, you already have a thread going there...
2025-04-17 23:44:45 <Ermine> the solution is to either patch out lazy loader or fix their generator to output PIE assembly
2025-04-17 23:44:53 <systemdlete> I'm happy to continue though
2025-04-17 23:45:14 <Ermine> and, shame on myself, I haven't figured out how to do that yet
2025-04-17 23:45:30 <systemdlete> no!
2025-04-17 23:45:37 <systemdlete> it's a feather in your cap!
2025-04-17 23:46:55 <systemdlete> so, did vbox devs respond?
2025-04-17 23:57:31 <Ermine> systemdlete: https://tpaste.us/8BKy 
2025-04-18 00:00:01 <systemdlete> Ermine, how did you get the GAs to pass in the pipeline?  E.g. 7.0.22.  Were these TEXTRELs an issue then also?
2025-04-18 00:00:42 <systemdlete> I mean, I am using the 7.0.22 even now (with 7.1.8 host) so it did make it through, but how?  Did you request an exception?
2025-04-18 00:17:10 <systemdlete> whoo-hoo!  My MR passed (finally!)
2025-04-18 00:18:30 <systemdlete> sans x86, of course.   But I'll keep at this, unless Ermine or someone else is already on it
2025-04-18 00:18:55 <psykose> nice :)
2025-04-18 00:19:41 <systemdlete> all good... not really... actually, not good.  I feel like I just cheated.
2025-04-18 02:16:47 <sertonix[m]> ncopa: If I remember correctly ABUILD_BOOTSTRAP disables checks in abuild but lua-aports doesn't exclude checkdepends in that case. That should probably be fixed.
2025-04-18 05:17:24 <Ermine> systemdlete: as it happens, 7.0.x line haven't used this lazy loafing for anything GA
2025-04-18 07:06:57 <anjan> Hey, can someone review: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/82032
2025-04-18 07:15:42 <systemdlete> Ermine, thank you for answering that.  So the first time you encountered this was when you tried to build the 7.1.x packages.  So you weren't able to build, say, 7.1.0 or so and that's when you chatted with vbox support (klaus-vb) etc.   It is making sense now.
2025-04-18 07:16:32 <systemdlete> But the question remains:  Are you going to continue pursuing this for the next GA package (7.1.10 I guess)?  I'm willing to help if you need it.
2025-04-18 07:17:41 <systemdlete> I don't know how much you are taking on.  I'm not trying to take over.
2025-04-18 07:17:58 <systemdlete> (There are plenty of other packages out there that could use support I am sure)
2025-04-18 07:50:20 <ncopa> i wonder if we should include apk-tools 3 for alpine 3.22 or wait merging it til right after the 3.22.0 release?
2025-04-18 07:50:28 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/82593
2025-04-18 07:51:07 <ncopa> What I'm mostly worried about is if apk-tools 3.0.0 release be tagged within a week or two
2025-04-18 07:51:20 <ncopa> so we dont ship an _rc* release of apk-tools
2025-04-18 08:17:57 <fabled> ncopa: if all goes well, I think I might tag by end of the month. but i'm currently on the road and there are some variables on how things go. I will be concentrating more on apk3 during May.
2025-04-18 09:35:23 <ncopa> ok
2025-04-18 09:35:48 <ncopa> I am almost done with the bootstrap of 3.22 builders
2025-04-18 09:42:42 <ncopa> what would the benefit be with including apk3 in alpine 3.22?
2025-04-18 09:43:01 <ncopa> it may give us a better upgrade path in the future?
2025-04-18 09:43:49 <fossdd[m]> yes it can be a wakeup call for other third party libapk users
2025-04-18 09:44:09 <fossdd[m]> maybe keep apk2 as a seperate package in community
2025-04-18 09:44:42 <ncopa> i think a static binary for apk2 may be enough
2025-04-18 09:45:13 <ncopa> i suppose other benefit with apk3 would be that it reduces apk2 maintenace
2025-04-18 09:45:29 <ncopa> the apk2 stable branch
2025-04-18 10:03:23 <ikke> ncopa: it would help us not defer it any further 
2025-04-18 10:31:04 <ncopa> yeha
2025-04-18 10:31:34 <ncopa> but there is no reason to not merge it directly after 3.22-stable branch
2025-04-18 10:31:47 <ncopa> or a week after 3.22 release
2025-04-18 10:32:03 <ncopa> then we have a full release cycle to fix the issues
2025-04-18 10:49:33 <ncopa> fabled, sertonix[m], ikke, fossdd[m]: do you think we should include apk3 or wait til after 3.22 release?
2025-04-18 10:49:47 <ncopa> need to merge it now if we decide to include it
2025-04-18 10:50:23 <ncopa> its this one: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/82593
2025-04-18 10:50:52 <ncopa> im thinking we will probably reduce stress if we wait til after 3.22
2025-04-18 10:51:08 <ikke> Yes, I agree.
2025-04-18 10:51:26 <fabled> Yes. Would probably be better to defer after 3.22 tagging. Especially if there is some time pressure now 
2025-04-18 10:54:26 <fossdd[m]> makes sense yeah
2025-04-18 11:19:31 <sertonix[m]> I don't have a strong opinion on this. I would just prefer to fix all the TODOs in the draft before merging.
2025-04-18 11:44:48 <ptrc> bit off-topic, but the protobuf upgrade missed some rebuilds
2025-04-18 11:45:20 <fossdd[m]> yeah see also !82692
2025-04-18 11:45:34 <ptrc> ah, thanks! was about to open one of my own
2025-04-18 11:45:45 <ptrc> aaand it's 6 days old, lol
2025-04-18 11:46:05 <ncopa> oh, i missed that. sorry
2025-04-18 11:46:08 <ncopa> lets merge it
2025-04-18 11:46:13 <ptrc> merged :)
2025-04-18 11:46:25 <fossdd[m]> thanks!
2025-04-18 11:46:40 <ptrc> there's still some broken deps on cdn.a.o, but they've been broken for a long while so it's not *that* urgent i guess
2025-04-18 11:46:50 <fossdd[m]> aaaaaahh git rebase now removed the mixxx rebuild commit
2025-04-18 11:47:08 <ptrc> it doesn't need a rebuild though, does it?
2025-04-18 11:47:24 <ptrc> for me it already builds with latest
2025-04-18 11:47:28 <ptrc> as in, .so.25
2025-04-18 11:47:33 <fossdd[m]> uhhh
2025-04-18 11:47:46 <ptrc> 74c86aa421642bd76d4a179e0b7d6042498275b9
2025-04-18 11:47:49 <fossdd[m]> ah lol it got rebuild against it with !82708 already
2025-04-18 11:47:50 <ptrc> this already rebuilt it against both :p
2025-04-18 11:47:50 <fossdd[m]> yeah
2025-04-18 11:47:58 <fossdd[m]> hehe
2025-04-18 16:05:00 <tmtt> Hello again, how do you handle unit tests that require external services (e.g. a redis cache) for the `check' step when porting a package to aports? I'm porting livekit and all their tests require redis / valkey, which I guess I can add to `checkdepends' but I don't know how to make sure the server is actually started afterwards (calling `service start valkey' in check() doesn't seem like the way to go)
2025-04-18 16:06:49 <ikke> tmtt: generally we have skipped such tests, but there are some packages that start something like postgresql or mysql in the check function
2025-04-18 16:07:28 <tmtt> I see
2025-04-18 16:09:35 <tmtt> I'll just add !check to 'options' and add a comment inside check() I think
2025-04-18 16:09:40 <tmtt> Thanks!
2025-04-18 16:16:09 <systemdlete> how long will it be until packages which passed the pipeline appear in the repos?  I can use my locally-built packages meantime, but I am just wondering what the process is, generally.  Thanks
2025-04-18 16:16:48 <ikke> systemdlete: The MR would need to be merged. After that, if there is nothing blocking the builders, then it should appear soon
2025-04-18 16:17:21 <systemdlete> Do I need to do anything further?
2025-04-18 16:17:56 <systemdlete> (check a box somewhere, e.g.)
2025-04-18 16:19:46 <ikke> Nope
2025-04-18 22:07:37 <WhyNotHugo> feedback for !78292, please?
2025-04-18 22:42:46 <ncopa> the 3.22 builders are up
2025-04-18 22:50:06 <dne> \o/
2025-04-18 22:51:33 <mio> \o/
2025-04-18 23:47:22 <Mangix> so
2025-04-18 23:47:28 <Mangix> is s390x big endian?
2025-04-18 23:47:54 <psykose> yes
2025-04-18 23:51:01 <Mangix> did it recently switch to little endian on edge?
2025-04-18 23:51:50 <Mangix> this CI workflow is failing endian tests on s390x. I don't remember this being a thing before
2025-04-18 23:52:20 <psykose> it can't switch to little endian
2025-04-18 23:53:21 <Mangix> then maybe std::endian recently broke
2025-04-18 23:53:29 <psykose> what ci workflow
2025-04-18 23:54:07 <Mangix> https://github.com/neheb/exiv2/actions/runs/14541982759/job/40801605447
2025-04-18 23:54:21 <Mangix> endianness is checked with std::endian::native
2025-04-19 00:00:31 <psykose> strongly doubt that is broken
2025-04-19 00:02:41 <Mangix> hrm I'll do more investigation. It's infortunate that s390x is the only big endian platform on setup-alpine
2025-04-19 00:03:58 <psykose> considering there's no other big endian ci and this run is after a bunch of endianness code changes what makes you think it's std::endian that's broken instead of the other commits you added right before it
2025-04-19 00:04:12 <psykose> rerun it before all the changes first at least
2025-04-19 00:04:53 <Mangix> probably because I can't read the le in ppc64le
2025-04-19 00:11:38 <quinq> They call it Le ppc64
2025-04-19 00:12:57 <Mangix> bien sur
2025-04-19 00:21:24 <quinq> :)