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> :)
2025-04-19 15:34:42 <xulfer> Workflow strikes me as market speak.  Anytime suddenly there's a new word for something we've already been doing for ages it's irksome.
2025-04-19 15:37:14 <xulfer> Soon I'll just be writing my code in an observable word pattern viewer to be run through a blazing fast gui-free compiler pipeline.
2025-04-19 15:47:59 <Newbyte> <xulfer> "Workflow strikes me as market..." <- what would you call it?
2025-04-19 15:56:25 <systemdlete> xulfer:  Like "deprecated?"  What was wrong with "obsolescent," other than the confusion over where the 'c' goes?  (And the fact that deprecate means to insult, not obsolesce!)
2025-04-19 15:57:08 <systemdlete> I could go on, but it would probably be faster and cheaper to just buy every developer a dictionary and a thesaurus... assuming they would use it.
2025-04-19 16:04:26 <systemdlete> a fellow tech bro of mine from years ago said, quite sapiently, that if they can't write well, they can't code well, either.  Ever notice how so many devs hate documenting their work--might be related!
2025-04-19 16:10:39 <craftyguy[m]> Languages have always changed over time. Like, you don't have to go that far back to find english words that are no longer being used...
2025-04-19 16:15:53 <systemdlete> craftyguy[m], consistency is all I am after.  Make it easy for ANYone to understand things.  If one starts using new lingo that most people are not accustomed to, especially today with the internet, it is likely that a lot of people will be confused.
2025-04-19 16:17:02 <systemdlete> And there are 7-8 billion people out there, many still struggling to even learn English, and with English having become (ironically) the Lingua Franca of the business and technical world, I think it behooves the privileged to be a bit less selfish with knowledge.  Say it in a way we can ALL understand.
2025-04-19 16:17:56 <systemdlete> It's just my 2c on this, and others are entitled to their opinions too, such as yourself.  You are right, of course, that languages do change over time.  But it should not be driven by a few people who hold the mic.
2025-04-19 16:19:24 <systemdlete> craftyguy[m], I am not even against people using "dived" instead of "dove" for the past tense.  I think weak forms are probably best because they keep the language simple and easy to learn for newcomers.
2025-04-19 16:19:58 <craftyguy[m]> Ya I agree, just pointing out that it's a moving target. Even native english speakers struggle (my small kid is dropping new language on me every day that they pick up from peers 😅)
2025-04-19 16:19:59 <systemdlete> Anything to help others.  But again, it is simplicity and consistency that is important.
2025-04-19 16:20:13 <systemdlete> omg.  So sorry for you LOL!
2025-04-19 16:21:41 <systemdlete> Even these "OMG" and "LOL" are hard for people.  One day, someone used "TIL" which I had never seen before.  It took me hours trying to find out what that meant, and finally I just ended up asking the nick who used it
2025-04-19 16:21:45 <systemdlete> "today I learned"
2025-04-19 16:22:43 <systemdlete> Even the Urban Dictionary isn't able to keep up with all of this.
2025-04-19 16:24:11 <systemdlete> Sorry for all this.  I just get so frustrated with this, on top of my hearing problem.  
2025-04-19 17:19:49 <mason> TANSTAAFL
2025-04-19 17:19:56 <mason> (there ain't no such thing as a free lunch)
2025-04-19 17:53:40 <xulfer> Yeah.  I do recognize it's irksome to me and not necessarily a valid critique!  I do think a lot of meanings are tacked on to sort of rebrand something, and other than that there's no reason for it.  Vernacular generally changes organically as needed.  I do not think in these cases it's needed.
2025-04-19 17:54:52 <xulfer> Ha I recognize the irony of dropping 'vernacular' there, but I couldn't think of a better word. :P
2025-04-19 20:43:22 <tmtt> Hey, I recently opened a merge request for a new package to the aports and someone pointed out a few issues on my APKBUILD. Since there should only be one commit by package (and by merge request), do I just make a new commit and call it a day or is there something on my end to do (like squash'ing my commits together)?
2025-04-19 20:45:45 <mio> tmtt: make the changes then squash the commits to one
2025-04-19 20:46:09 <mio> same MR, no need to open a new one
2025-04-19 20:46:37 <tmtt> I'll do that then thanks
2025-04-19 20:53:00 <tmtt> No need to bump `pkgrel` since it's not already commited right?
2025-04-19 20:54:37 <mio> yes
2025-04-20 07:50:08 <ncopa> im bootstrapping rust on build-3-22-{riscv64,ppc64le} now
2025-04-20 07:52:56 <ncopa> and loongarch64
2025-04-20 07:56:58 <ncopa> and the rest of the arches
2025-04-20 13:01:35 <fossdd[m]> can somebody please merge !76192 its been ready for 4 months already :p
2025-04-20 13:24:00 <fossdd[m]> sweet thanks
2025-04-20 13:25:05 <omni> good if it has an active maintainer
2025-04-20 13:44:56 <omni> one of their other aports, community/img, hasn't moved upstream in a while https://github.com/genuinetools/img
2025-04-20 15:50:10 <fossdd[m]> fwiw !82900 and !82805 are also ready
2025-04-21 05:38:42 <Saijin_Naib[m]> Anyone have the bandwidth to check/merge !82725 so we can use Pinta 3.x goodness?
2025-04-21 05:40:13 <ikke> pipeline is still running
2025-04-21 05:43:25 <Saijin_Naib[m]> Yeah, I just kicked off another rebase, prior one passed after mio fixed it up for me
2025-04-21 05:44:01 <ikke> It just finished
2025-04-21 05:46:18 <Saijin_Naib[m]> Sweet!
2025-04-21 19:18:57 <xordspar0> Hi all, my new aport MR has been waiting for review for longer than usual. Is there anything I can do do make my MR easier for reviewers? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/79093
2025-04-21 19:19:34 <xordspar0> I'm not complaining, and I appreciate the work all the volunteers do! If the answer is "too many MRs, not enough time" that's fine.
2025-04-21 19:23:53 <ikke> Yeah, it's the latter mostly
2025-04-21 19:53:01 <realroot[m]> I packaged a game should I try to MR? i took the last commit since i see no tags
2025-04-21 19:55:42 <realroot[m]> not sure what debian use as source https://salsa.debian.org/games-team/openarena.
2025-04-21 19:55:43 <realroot[m]> I used AUR and nixOS packages
2025-04-21 20:27:53 <rhizoome> realroot[m]: if your question was: what to set as source for openarena: https://sourceforge.net/projects/oarena/files/openarena-$pkgver.zip/download
2025-04-21 21:16:25 <xordspar0> ikke: Ok, thanks. I wondered if there was a problem with my MR in particular because I beleive it's the oldest open non-stale new aport MR.
2025-04-21 21:18:13 <xordspar0> Ah, that's probably just because I've been preventing it from going stale by merging main into my branch periodically. :)
2025-04-21 21:23:46 <Saijin_Naib[m]> Is unmaintained still a thing? I want to bring dxvk back top edge, as I need it to run Paint.NET under WINE, apparently
2025-04-21 21:23:59 <ikke> Saijin_Naib[m]: no, there is no unmaintained repo
2025-04-21 21:24:32 <Saijin_Naib[m]> How do I move dxvk aport out, or do I just copy the latest apkbuild from a stale MR from 2022 and update accordingly?
2025-04-21 21:25:09 <ikke> yeah, copy it to testing
2025-04-21 21:29:17 <Saijin_Naib[m]> Sweet, fingers crossed this works
2025-04-22 00:20:14 <xordspar0> ikke: Thanks for the review!
2025-04-22 03:53:45 <Saijin_Naib[m]> I am struggling with dxvk. I put vulkan-dev (or vulkan-loader-dev along with vulkan-dev) in makedepends and it never pulls in vulkan-dev, which I need to provide vulkan.h for build
2025-04-22 03:56:23 <Saijin_Naib[m]> !83090
2025-04-22 03:56:45 <Saijin_Naib[m]> One of the makedepends has a !vulkan-headers rdep or something?
2025-04-22 06:03:25 <Justin[m]> Hey team, I'm trying the alpha cloud images on Digital Ocean and it boots OK but the root and alpine accounts aren't able to used via the recovery console as they likely have no password. nmap shows port 22 as filtered.
2025-04-22 06:04:43 <Justin[m]> Digital Ocean use cloud-init as I can see that pre-installed on their provided images.
2025-04-22 06:07:17 <fossdd[m]> you have no crossfile
2025-04-22 06:07:35 <fossdd[m]> ah its in the repo
2025-04-22 06:09:10 <fossdd[m]> i would try building without it
2025-04-22 06:14:57 <Justin[m]> <fossdd[m]> "you have no crossfile" <- I'm not building images, just downloading them from the website.
2025-04-22 06:15:01 <Justin[m]> I found https://github.com/benpye/alpine-droplet
2025-04-22 06:15:34 <Justin[m]> Which looks legit and like it would do what I need.
2025-04-22 06:15:46 <Justin[m]> Maybe Alpine could build DO images with this as a reference.
2025-04-22 06:19:45 <fossdd[m]> it would probably make more sense to integrate it into https://gitlab.alpinelinux.org/alpine/cloud/alpine-cloud-images
2025-04-22 06:21:42 <Justin[m]> I tried the script I found but it bails:... (full message at <https://matrix.org/oftc/media/v1/media/download/ATLs4OIsb_bRx30Me-JJvQp_dposqLDJSAoODVwQTxMA0kPYB6OMTs2ZLjOgwYdI0i2ri6AmD0qg9AKrKTAv0i1CeWpEHf9wAG1hdHJpeC5vcmcvQnFnS3FrcEVIeEpFaEVJdFVRV0pPZkxS>)
2025-04-22 06:36:12 <ikke> Justin[m]: the cloud-init images expect you to ssh into the alpine user with a key provided through IMDS
2025-04-22 06:37:55 <Justin[m]> ikke: Yeah, I tried that, something isn't working because the ssh port is filtered.
2025-04-22 06:47:10 <Justin[m]> tomalok: would you be interested in helping me build a Digital Ocean cloud image?
2025-04-22 07:10:29 <Justin[m]> Awesome, the script worked once I got the hang of it.
2025-04-22 07:10:50 <Justin[m]> A webserver with 68 packages (even after intalling fish for my own selfish reasons...)
2025-04-22 07:10:52 <Justin[m]> 103.6MB used on /
2025-04-22 07:13:35 <Justin[m]> Doesn't even hit 1% of a 25GB volume 😆
2025-04-22 10:55:13 <ncopa> i think it shouldnt be too difficult adding support for digital ocean. https://gitlab.alpinelinux.org/alpine/cloud/tiny-cloud/-/tree/main/lib/tiny-cloud/cloud?ref_type=heads
2025-04-22 10:58:03 <Justin[m]> ncopa: Yeah I hope so.
2025-04-22 13:29:29 <f_[m]> <Justin[m]> ncopa: Yeah I hope so.
2025-04-22 13:29:29 <f_[m]> folks at #alpine-cloud might be able to help you if you're up to the task ^^
2025-04-22 13:30:21 <Justin[m]> Ah thanks f
2025-04-22 13:30:43 <f_> *f_
2025-04-22 13:30:45 <f_> np
2025-04-22 13:59:56 <hecmec> where are the scripts that are used to generate the release isos?
2025-04-22 14:07:09 <hecmec> is it this? https://github.com/alpinelinux/aports/tree/master/scripts
2025-04-22 14:08:51 <ikke> Yes
2025-04-22 14:36:26 <ncopa> yes. they are invoked by https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/aports-build/aports-build which is triggered by mqtt message from git hook
2025-04-22 14:40:24 <hecmec> thank you!
2025-04-22 15:17:43 <ncopa> Anyone know why this fails? curl -L  https://www.squid-cache.org
2025-04-22 15:17:56 <ncopa> curl: (60) SSL certificate problem: unable to get local issuer certificate
2025-04-22 15:18:10 <ikke> ncopa: guess: they don't sent intermediates
2025-04-22 15:18:27 <f_> ncopa I get
2025-04-22 15:18:28 <f_> curl: (60) SSL peer certificate or SSH remote key was not OK
2025-04-22 15:19:55 <ncopa> also happens with ubuntu
2025-04-22 15:20:04 <ikke> Verification error: unable to verify the first certificate
2025-04-22 15:20:18 <ikke> with openssl s_client -connect www.squid-cache.org:443
2025-04-22 15:22:45 <ikke> ncopa: yeah, the intermediate they send is different from the one that signed it
2025-04-22 15:22:57 <ikke> Leaf:  i:C=US, O=Let's Encrypt, CN=R10
2025-04-22 15:23:07 <ikke> Intermediate: s:C=US, O=Let's Encrypt, CN=R11
2025-04-22 15:23:16 <ikke> CN=R10 vs CN=R11
2025-04-22 15:23:44 <ikke> Browsers automatically fetch / cache the intermediates, so they can still verify it, but tools like curl / openssl don't
2025-04-22 15:26:24 <ncopa> not sure where to report it
2025-04-22 15:28:17 <ncopa> im copying the file manually on distfiles to .../v3.2"/
2025-04-22 15:28:20 <ncopa> v3.22/
2025-04-22 15:28:31 <ikke> Do they have a mailing list or something like that?
2025-04-22 15:28:51 <ncopa> they appear to have a handful of mailing lists
2025-04-22 15:30:30 <ikke> And bugzilla, but I suppose that's only for bugs related to the software
2025-04-22 15:32:27 <ikke>  noc@lists.squid-cache.org perhaps?
2025-04-22 19:04:01 <bl4ckb0ne> > ERROR: intel-graphics-compiler-2.10.8-r0.apk: package file format error
2025-04-22 19:04:07 <bl4ckb0ne> i remember hitting that recently
2025-04-22 19:04:16 <bl4ckb0ne> but i dont remember what was the fix
2025-04-22 19:14:09 <ikke> bl4ckb0ne: usually it means some metadata field is invalid
2025-04-22 19:14:43 <psykose> another +0 ver in .pc, prolly libiga64.so.2.10.0+0
2025-04-22 19:15:07 <psykose> or libigdfcl.so.2.10.0+0
2025-04-22 19:15:21 <bl4ckb0ne> ah right the so with the messed up name thanks psykose 
2025-04-22 19:41:05 <craftyguy[m]> mcrute: would you mind taking a look at !82456 ? thanks :)
2025-04-22 20:57:00 <intr> just letting you know Dovecot is completely broken on edge, segfaults with minimal correct config (errors out with incorrect config), I saw there was a report already but it's 3 weeks old https://gitlab.alpinelinux.org/alpine/aports/-/issues/17050
2025-04-22 21:01:32 <ikke> Not sure if related: https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/F5FJJZT6OR467TCY4W5GUZFTPKURZBHR/
2025-04-22 21:02:59 <intr> ikke: sounds identical to my problem
2025-04-22 21:03:49 <intr> I ended up reverting my alpine setup to latest stable with a backup config, fine for now
2025-04-22 21:05:44 <ikke> Could you add that link to the issue? (I'm not logged in atm on this device)
2025-04-22 21:07:27 <intr> I don't have an account 
2025-04-22 21:07:53 <ikke> ok
2025-04-22 21:17:40 <mio> added to the issue
2025-04-22 21:18:28 <intr> thank you
2025-04-22 21:34:51 <Saijin_Naib[m]> Anyone seen a makedepends just refuse to install during abuild despite being explicitly set and no error reported? !83090
2025-04-22 21:34:58 <Saijin_Naib[m]> This is new to me
2025-04-22 21:35:50 <fossdd[m]> as i commented, its getting installed
2025-04-22 21:36:09 <fossdd[m]> someone here for merging !82805 and !82900 ^^
2025-04-22 21:36:41 <fossdd[m]> they should both the boring bug fixes only
2025-04-22 21:36:43 <fossdd[m]> or mostly
2025-04-22 21:38:27 <Saijin_Naib[m]> @fossdd ah sorry, did not see.  Locally it does not install, but yeah, CI is different, apparently
2025-04-22 21:38:46 <fossdd[m]> maybe its already installed locally
2025-04-22 21:39:05 <Saijin_Naib[m]> Nah, apk list shows it not installed
2025-04-22 21:39:38 <Saijin_Naib[m]> It installs all other makedepends and just silently drops that one locally
2025-04-22 21:40:07 <Saijin_Naib[m]> Not using abuild-rootbld, though, so maybe that is on me
2025-04-22 21:40:15 <Saijin_Naib[m]> Just regular abuild
2025-04-22 21:40:51 <fossdd[m]> should still work
2025-04-22 21:41:16 <fossdd[m]> what happens if you apk add !vulkan-headers
2025-04-23 06:11:34 <Saijin_Naib[m]> That breaks world/build
2025-04-23 06:11:49 <Saijin_Naib[m]> Let me try again with vulkan-headers definitely purged from my system now
2025-04-23 06:23:24 <Saijin_Naib[m]> Mmm, still can't find vulkan.h
2025-04-23 06:23:29 <Saijin_Naib[m]> This one is beyond me
2025-04-23 06:41:05 <psykose> it's missing the submodules
2025-04-23 06:41:14 <psykose> builds fine
2025-04-23 06:47:18 <ncopa> intr: has the dovecot issue been reported upstream? im 90% sure its a but in dovecot
2025-04-23 07:39:22 <intr> ncopa: the issue reported on dovecot's mailing list seems very similar. In my case however, not even dovecot itself wants to start
2025-04-23 12:50:21 <Habbie> ncopa, intr, i mentioned it to dovecot upstream, and told them they can find y'all here. They want you to know you can also find them in #dovecot :)
2025-04-23 12:53:44 <ikke> Same network?
2025-04-23 12:54:24 <f_> ikke: I suppose
2025-04-23 12:54:31 <f_> - ChanServ: Channel information for #dovecot
2025-04-23 12:54:36 <f_> - ChanServ:     Description: Dovecot Official Channel
2025-04-23 14:05:23 <ncopa> seems like libks is still deadlocking
2025-04-23 14:08:41 <elagost> would someone be able to look at this mr? would like to get it in before 3.22. !82832
2025-04-23 15:01:39 <pabloyoyoista|m> Hey, could anybody have a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/82534
2025-04-23 15:02:07 <pabloyoyoista|m> it's been opened for a few weeks, I maintain it upstream, and the maintainer downstream has also approved it
2025-04-23 15:05:45 <pabloyoyoista|m> Also if somebody can add https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/82800 to the usr merge milestone would be amazing!
2025-04-23 15:26:30 <craftyguy[m]> There are a few MRs that need to be added to that milestone, I don't have permissions to do it either. If someone with enough perms can add them, I can list them out... lmk
2025-04-23 15:27:45 <ikke> craftyguy[m]: can you link them?
2025-04-23 15:29:51 <craftyguy[m]> sure, one moment
2025-04-23 15:32:30 <craftyguy[m]> !82456 !83131 !82463 !83130 !83128 !83141 !83132  (and the one that Pablo pointed out above too)
2025-04-23 15:36:11 <ikke> done
2025-04-23 15:38:51 <craftyguy[m]> thank you! :D
2025-04-23 16:05:30 <craftyguy[m]> Is the aarch64 edge builder stuck for some reason? It has been "signing the index" for libgdiplus for a long time
2025-04-23 16:06:02 <craftyguy[m]> no obvious failure I can see in the public build log
2025-04-23 16:06:46 <ikke> it's building mono..
2025-04-23 16:08:47 <craftyguy[m]> Ah I thought it hadn't started on mono yet because the build log for that 404s: https://build.alpinelinux.org/buildlogs/build-edge-aarch64/community/mono/mono-6.14.0-r0.log
2025-04-23 16:10:10 <ikke> the builder only uploads it after it finished / failed
2025-04-23 16:10:55 <craftyguy[m]> oh ok, I didn't realize that. Sorry for the noise :)
2025-04-23 16:49:11 <ikke> Np
2025-04-23 21:05:02 <craftyguy[m]> ooook now mono failed on aarch64 🙃
2025-04-23 21:08:43 <craftyguy[m]> I don't see anything obvious in the log, maybe it OOMed or is there a timeout on the builder that kills something if it takes "too long"?
2025-04-23 21:22:09 <f_> craftyguy[m]: in -infra: > I guess mono is hanging on aarch64
2025-04-23 21:22:15 <f_> > no new log output
2025-04-23 21:22:27 <f_> guess it timed out
2025-04-23 21:27:38 <craftyguy[m]> Log says it was terminated, but it doesn't seem to be the build system/make that ended it, which is why I asked if it hit some alpine build system timeout (or OOM'd)
2025-04-24 09:35:55 <rhizoome> craftyguy[m]: you can increase the ti
2025-04-24 09:36:34 <rhizoome> timeout in the settings of your for, by default it is 1h.
2025-04-24 09:37:03 <rhizoome> s/your for/your fork/
2025-04-24 09:37:49 <rhizoome> settings > CI/CD > General
2025-04-24 10:07:39 <Cogitri> Hej, is someone running apk-tools3 already?
2025-04-24 10:07:52 <Habbie> Cogitri, openwrt perhaps
2025-04-24 10:08:25 <ncopa> im running it locally
2025-04-24 10:08:31 <Cogitri> I was testing apk-polkit-rs w/ the new API but seems like apk-tools3 in general doesn't like the state of my machine :D
2025-04-24 10:08:55 <ncopa> works fairly ok here
2025-04-24 10:09:16 <Cogitri> Hm, any command that actually interacts with world ends up printing
2025-04-24 10:09:21 <Cogitri> ERROR: unable to select packages:
2025-04-24 10:09:26 <Cogitri> Huh? Error reporter did not find the broken constraints.
2025-04-24 10:10:09 <Cogitri> Seems to happen for any package or when doing apk upgrade -as - both of which work fine with apk-tools 2.14.10
2025-04-24 10:10:21 <fossdd> uhh thats probably a solver or a packaging issue
2025-04-24 10:10:35 <ncopa> i have a static apk2 installed as well so I can compare
2025-04-24 10:10:41 <fossdd> i've had these in the past but couldnt reproduce it anymore
2025-04-24 10:11:11 <fossdd> maybe you can bisect it in a new root with removing packages from /etc/apk/world
2025-04-24 10:11:31 <Cogitri> Ah I have a debugger attached, it has some 7 solver errors, let's see which packages it complains about
2025-04-24 10:13:38 <fabricionaweb> this looks shit, I think I need to create two MR !83164
2025-04-24 10:17:20 <Cogitri> Seems like it complains about pipewire and that propagates upwards to the packages that depend on it
2025-04-24 10:17:57 <Cogitri> I'm currently running on pmOS to test GNOME Software on that, so if pipewire works for you on apk-tools3, it might be due to pmOS' changes to the APKBUILD
2025-04-24 11:04:51 <fossdd> is someone here who wants to take a look at !82805 and !82900 ? :3
2025-04-24 12:23:54 <ncopa> im lisghtly worried about the build-3-22-riscv64, which is falling behind
2025-04-24 12:23:58 <ncopa> slightly*
2025-04-24 12:57:09 <ikke> Ok, I'm puzzled
2025-04-24 12:57:16 <ikke> which iostat
2025-04-24 12:57:20 <ikke> /usr/bin/iostat
2025-04-24 12:57:29 <ikke> /usr/bin/iostat -x # works
2025-04-24 12:57:44 <ikke> iostat -x # bb iostat complaining it does not know -x
2025-04-24 12:58:53 <fossdd> maybe re-login
2025-04-24 13:00:28 <Habbie> note that 'which' is not a builtin
2025-04-24 13:00:52 <Habbie> 'type iostat' will tell you what ash thinks iostat is
2025-04-24 13:01:03 <Habbie> 'hash -r' may help instead of re-login
2025-04-24 13:01:24 <Habbie> s/ash/busybox sh/
2025-04-24 13:02:03 <ikke> Hmm, never experienced that before with ash / bb sh
2025-04-24 13:02:29 <Habbie> wait, /usr/bin?
2025-04-24 13:02:44 <Habbie> so you have /bin/iostat and /usr/bin/iostat ?
2025-04-24 13:03:12 <ikke> apparently, probably due to /usr/ merge
2025-04-24 13:03:22 <Habbie> hmm my /usr is not merged
2025-04-24 13:03:29 <ikke> No, preparation
2025-04-24 13:03:35 <Habbie> ok, then all makes sense
2025-04-24 13:03:44 <Habbie> (to me, so far)
2025-04-24 13:04:23 <ikke> I was not aware of ash hashing executables
2025-04-24 13:04:31 <Habbie> i could be entirely wrong
2025-04-24 13:04:35 <Habbie> as your situation is explained now
2025-04-24 13:04:46 <Habbie> (i hope)
2025-04-24 13:05:00 <ikke> It worked after relogin
2025-04-24 13:05:09 <ikke> PATH is still the same
2025-04-24 13:05:09 <Habbie> oh.
2025-04-24 13:05:28 <ikke> I did not run type iostat sadly before doing that
2025-04-24 15:08:32 <craftyguy[m]> Could !83181 also get added to the usr merge milestone please?
2025-04-24 15:37:45 <craftyguy[m]> thank you ikke!
2025-04-24 15:40:21 <pabloyoyoista|m> Cogitri: have you opened an issue with the solver errors you encountered? This seems to only be an issue with downstream systemd-pmOS, so would be good to have solved before
2025-04-24 15:43:34 <pabloyoyoista|m> Aha, already found the apk-tools issue, sorry for that
2025-04-24 15:44:30 <Cogitri> No worries :)
2025-04-24 16:24:02 <pabloyoyoista|m> ikke: regarding iostat. I've looked at the history and that bug of it being in different locations seems not related to /usr merge
2025-04-24 16:24:18 <pabloyoyoista|m> Seems we haven't touched it ourselves
2025-04-24 16:24:40 <pabloyoyoista|m> So might be upstream changed the path in the latest update, or that it's been a packaging bug for years
2025-04-24 16:25:46 <Habbie> on edge it ends up in /bin, replacing the busybox symlink, for me
2025-04-24 16:27:14 <pabloyoyoista|m> Yes, that's after we fixed it: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/83131
2025-04-24 16:33:50 <craftyguy[m]> Yeah before that patch there were two versions of it installed, one from busybox and one from sysstat. Which one you got depended on how you set PATH 😅
2025-04-24 17:09:01 <intr> Habbie: re dovecot: thanks, I'll join their channel
2025-04-24 17:11:02 <ikke> pabloyoyoista|m: ok
2025-04-24 17:20:30 <ncopa> craftyguy[m]: rather than moving binaries from GNU utils to /bin, wouldnt it be better to move the busybox symlink to /usr? 
2025-04-24 17:20:47 <ncopa> This shows one way it could be done: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/83217
2025-04-24 17:21:11 <ncopa> but we should probably keep /bin/sh, and maybe /sbin/nologin, which are in /etc/passwd
2025-04-24 17:37:49 <remexre> my company uses alpine VMs, and we're considering starting to package the (internal-only, not generally interesting) software we deploy on them with apk
2025-04-24 17:38:11 <remexre> is it easy to use abuild / alpine-sdk for this without aports?
2025-04-24 18:00:43 <ptrc> remexre: i'd say yes, but that depends on your setup
2025-04-24 18:00:52 <rhizoome> remexre: well, you install abuild, make key, create a directory, like my_company/my_package, put APKBUILD in there, many fields are not needed, but abuild will show warning. the only function you really need is package() {} there you copy files into $pkgdir. and you get a package in $HOME/packages/my_company/$arch/my_package-$pkgver
2025-04-24 18:01:28 <remexre> okay, sweet, just wanted to make sure it was supported before i start on this
2025-04-24 18:01:57 <ptrc> you might also be interested in lua-aports for tools like `buildrepo`
2025-04-24 18:01:59 <rhizoome> remexre: abuild will complain about things that are not correct for alpine, but I think it will do most things.
2025-04-24 18:02:13 <ptrc> ( basically, checks which packages are out of date and builds all of them )
2025-04-24 18:03:03 <ptrc> rhizoome: i haven't had abuild complain even once on my personal repo, even with rootbld and all
2025-04-24 18:03:32 <craftyguy[m]> ncopa: I thought this was discussed somewhere previously, but maybe I'm not recalling correctly. Ya there would need to be special cases for some binaries that tend to have paths hardcoded in other things/scripts... This is all kind of temporary anyways since once /usr is merged then it kinda won't matter which dir busybox/other stuff is installed in since it'll all point to the same location (except /usr/sbin, which might continue to
2025-04-24 18:03:32 <craftyguy[m]> cause some pain as an outlier)
2025-04-24 18:03:40 <remexre> we'd be doing the builds in CI, and I was intending to build everything every time to check for reproducibility -- would it still be useful then, or would some flavor of find -name APKBUILD -exec dirname {} \; be "good enough"
2025-04-24 18:04:48 <rhizoome> remexre: and abuild is easy to hack, if you need something a bit different.
2025-04-24 18:05:10 <ptrc> well, buildrepo makes sure you build stuff in the correct order, so nothing fails on missing dependencies
2025-04-24 18:05:37 <remexre> ptrc: ah, okay, that's nice; i'll make sure checking it out is on my list
2025-04-24 18:05:53 <craftyguy[m]> ncopa: I saw your pmaports patch (kinda surprised busybox doesn't use prefix= or something to redirect stuff on install heh), I'll think about this some more, and probably chat with Pablo about it
2025-04-24 18:06:27 <ptrc> i suppose you could pass a different `--destdir` parameter for buildrepo so it outputs into a CI-build-specific directory, then compare with previous runs
2025-04-24 18:07:28 <rhizoome> ptrc: abuild really hates textrels: https://gitlab.alpinelinux.org/systemdlete/aports/-/jobs/1812843#L392 
2025-04-24 18:08:11 <ptrc> also, for reproduciblity, you'd want to pass env variable `SOURCE_DATE_EPOCH` to some unix timestamp
2025-04-24 18:08:41 <ptrc> rhizoome: yeah you can just set the `textrels` option and it works fine, it's not aports-specific
2025-04-24 18:08:57 <rhizoome> but option="textrels" will fix it.
2025-04-24 18:11:18 <psykose> it 'hates textrels' because musl can't actually load code that has textrels
2025-04-24 18:12:15 <rhizoome> oh thats why we need -fPIC, right?
2025-04-24 18:12:19 <psykose> yes
2025-04-24 18:13:29 <craftyguy[m]> ncopa: just thinking out loud here... I also think we probably have most of the stuff fixed now wrt conflicting with busybox in /bin. if we move BB stuff to /usr, then we'd have to revert a bunch of stuff that overwrites BB apps in /bin. It's not a big deal, just some more work / potential breakage. Maybe from the start we should have thought to try moving BB to /usr... maybe we did (and hence my comment that I thought this was
2025-04-24 18:13:30 <craftyguy[m]> discussed before... but until I find that issue/comments... 🤷‍♂️)
2025-04-24 18:14:02 <craftyguy[m]> The tests that Pablo and I have been developing/running for /usr merge should be passing after the latest round of patches (currently waiting on sysstat on the builder)
2025-04-24 18:52:03 <craftyguy[m]> could someone please merge !82534 ?
2025-04-25 05:20:32 <ncopa> yeah, im thinking we should have done this from the start, but I havent had the time, so I justs merged the MRs to move bins to /bin
2025-04-25 05:21:07 <ncopa> I find it cleaner to fix the busybox links than patching N packages, but I suppose it is late for that now
2025-04-25 05:21:22 <ncopa> sorry that I havent had time to help with that earlier
2025-04-25 05:22:49 <ncopa> the idea was to avoid moving them back and forth, but I realize its late for that now
2025-04-25 05:22:57 <ncopa> did know how many of those you had left
2025-04-25 05:31:16 <craftyguy[m]> No problem :) Once the merge is done then we could back out many/all of these patches (or not, it shouldn't matter functionally), since BB links and apps from other packages will be the same location whether the build system installs to /bin or /use/bin 😛
2025-04-25 06:05:07 <ncopa> whats up with the 3.21 builders?
2025-04-25 06:05:09 <ncopa>   qt6-qtbase-private-dev (no such package):
2025-04-25 06:05:09 <ncopa>     required by: .makedepends-qt6-qtpositioning-20250425.031512[qt6-qtbase-private-dev]
2025-04-25 06:09:01 <ncopa> 431a7939d75191b9978e784a7b371db1ebc719c5
2025-04-25 06:09:18 <ncopa> but 735a851a417f72e52480342104b2b86ad3ddc055 was not cherry-picked
2025-04-25 06:14:06 <ncopa> PureTryOut: do you have time to follow up on the 3.21 builders? or should I just revert 431a7939d75191b9978e784a7b371db1ebc719c5?
2025-04-25 06:42:23 <ncopa> efitools fails to build on riscv64 due to sbsigntool failure: Invalid DOS header magic
2025-04-25 06:42:37 <ncopa> i wonder if this is related the broken gnuefi?
2025-04-25 06:43:00 <ncopa> weird that it only happens on riscv64
2025-04-25 07:16:31 <PureTryOut> oh I'll fix the -private thing
2025-04-25 07:46:28 <ncopa> there are lots of qt6-qtdeclarative-private-dev introduced in http://dup.pw/alpine/aports/431a7939d751
2025-04-25 07:49:12 <ncopa> oh, that was master not 3.21-stable
2025-04-25 08:04:21 <PureTryOut> Yeah master is fine
2025-04-25 14:16:17 <ptrc> PureTryOut: a bugfix MR for your consideration: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/83245
2025-04-25 15:59:43 <craftyguy[m]> so... I forgot to reset a pkgrel to 0 after bumping pkgver the other day, I want to make a change to the package now that should have the pkgrel bumped for it. Should I set the pkgrel to what it should be had I reset it to 0, or should I pkgrel++ it?
2025-04-25 15:59:55 <psykose> always ++
2025-04-25 16:00:05 <craftyguy[m]> ok thanks :)
2025-04-25 16:00:07 <Habbie> yeah if it was merged, never go down
2025-04-25 16:02:24 <craftyguy[m]> in the pmOS aports CI we have a test that checks if pkgrel and pkgver are set according to expectations (and fails with a warning if not), would a similar test be desirable in aports pre-merge CI? it would have caught my mistake :P
2025-04-25 16:03:20 <Habbie> openwrt also has or had one like that
2025-04-25 16:03:51 <craftyguy[m]> I guess it's not perfect, there are lots of cases where checksums might change but pkgver should stay the same (e.g. config files in pkg that are installed, etc)
2025-04-25 16:04:03 <craftyguy[m]> anyways, thanks for the help :P
2025-04-25 16:04:11 <Habbie> well, then pkgrel changes, right?
2025-04-25 16:04:19 <Habbie> you'd have to compare against the previous one
2025-04-25 16:06:58 <craftyguy[m]> https://gitlab.postmarketos.org/postmarketOS/pmaports/-/blob/master/.ci/lib/check_changed_aports_versions.py?ref_type=heads#L139
2025-04-25 16:07:02 <craftyguy[m]> that's the check we use in pmOS (ignore the bits earlier abiout device pkgs and stuff)
2025-04-25 16:07:17 <craftyguy[m]> in theory this could be adapted for aports if it would be useful
2025-04-25 16:09:23 <craftyguy[m]> it migth cause more noise than good though, e.g. if you updated some /etc/init.d/thing in aports, the checksum would change, but pkgver would probably stay the same and pkgrel++, the check there would fail and throw a warning in CI
2025-04-25 17:36:36 <amf3> Hi all.  I have an open MR to fix a broken cloud-init package in aports: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/82091 and I think @fossdd may be unavailable.  Could someone else review or help move the MR forward? Changes were tested with output in the comments and the commit has been squashed.  Thanks for the assistance.
2025-04-26 03:22:19 <qaqland> amf3: fossdd is always active
2025-04-26 08:54:45 <Piraty> 9cbf1cc9fd6 ("community/firefox-esr: upgrade to 128.9.0")  broke it for me, it reliably crashes on startup
2025-04-26 09:31:09 <knuxyl> I just created an APKBUILD for logiops in a fork of aports. I've been following the guide but I would like some input before I go further. This is my first time actually using git.
2025-04-26 09:31:09 <knuxyl> https://gitlab.alpinelinux.org/knuxyl/logiops-openrc/-/tree/master/testing/logiops-openrc?ref_type=heads
2025-04-26 09:48:31 <rhizoome> the filestructure of the resulting packages in the CI logs.
2025-04-26 09:48:31 <rhizoome> knuxyl: it looks nicely structured! That git clone in build is thing one should not do. Is the source you download not containing everyhing? Then you should probably do subpackages, but I can only tell, if I see the file-structure of the resulting packages. So I would propose that you do MR. You can set the MR to draft, so nobody thinks you are trying to submit something unfinished. Then you get output from the linter and reviewers can see 
2025-04-26 09:54:11 <rhizoome> knuxyl: it looks like that git clone, should actually be seperate package with its own APKBUILD. You can add two packages in a single MR. You need to make it two commits though.
2025-04-26 10:05:18 <knuxyl> ll after it was fixed so the only way to get the latest with these fixes is by cloning the repo. ipcgull just builds a static libipcgull.a for logiops to link to. Void linux seems to be just including the initial release file for ipcgull as a "distfiles" which is probably like our "source" and ipcgull is not available in void linux. ill try removing the cloning and adding the release file. ill need to test if it builds but i guess 
2025-04-26 10:05:18 <knuxyl> well the dependency on ipcgull is not something installed, it's purely a build dependency and is only used for this package. the developer split it into another program instead of just adding the capability to logiops itself. i don't think adding another aports package would be appropriate for this because logiops is the only program that uses it. also there were some build issues and the developer never released an update to ipcgu
2025-04-26 10:06:33 <knuxyl> Here is what void does     https://github.com/void-linux/void-packages/blob/master/srcpkgs/logiops/template
2025-04-26 10:08:40 <knuxyl> I think maybe it would be ok to add ipcgull-static package but I'll probably have to modify the cmake of logiops itself and i hate messing with cmake. The best option I recommend is to just include the release file as a source and build with it instead of adding ipcgull as another package though.
2025-04-26 10:08:43 <rhizoome> knuxify: we usually do make packages for header-only or build only dependencies. Because we track security issues and version changes that way. 
2025-04-26 10:09:36 <fossdd[m]> amf3: sorry didnt had the time yet to take a deeper look
2025-04-26 10:09:53 <rhizoome> We actually end up this being only one package it should be downloaded via source=
2025-04-26 10:14:00 <knuxyl> Yeah that's what I'm suggesting. I left all the .preinstall type files as default, I didn't need to do anything with them i dont think. i installed the service file in the package() function but I'm not sure if I needed to do some special openrc stuff.
2025-04-26 10:15:44 <rhizoome> knuxify: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests here are the merge requests. gitlab should ask if you want to open a MR if you push changes to your branch. Otherwise you can manually create one on gitlab.
2025-04-26 10:17:30 <knuxyl> ah ok i didnt know MR meant merge request. I see the button the page now. thank you
2025-04-26 10:37:18 <knuxyl> i have fixed the package and added it as a source and included another patch for ipcgull because it wouldn't build without the latest changes. do i commit with the same message? "git commit -m "testing/logiops-openrc: new aport""
2025-04-26 10:40:49 <rhizoome> knuxify: you can git commit —amend then it adds the changes to the latest commit.
2025-04-26 10:44:04 <knuxyl> ok thank you
2025-04-26 11:11:14 <knuxyl> is it ok to add the openrc service to default and start it in the .post-install file?
2025-04-26 11:16:03 <rhizoome> if you mean „rc-update add“ in post-install, no alpine want no hidden magic. The user has to decide how to start it.
2025-04-26 11:16:51 <knuxyl> ok thank you
2025-04-26 11:27:50 <knuxyl> ok thanks everyone, i create a merge request in draft : )
2025-04-26 11:28:54 <knuxyl> the logiops daemon is useful for logitech mx master 3, i set the scroll wheel as volume and side buttons and zoom function with this program.
2025-04-26 11:54:22 <mid> Hi all. I wrote an nginx module and I'd like to make an Alpine package of it, first just for myself (for convenience in some still unpublished personal project) and maybe eventually in the official Alpine distro. As with all nginx modules, it must be built with access to nginx source. Moreover, nginx is picky about the module building configuration and uses a module signature scheme to check modules' compatibility. The maintainer of 
2025-04-26 11:54:22 <mid> the nginx* packages is Jakub and AFAIK they're not available here. I hope someone here will be able to help with this, or to tell me if I need to contact Jakub (by email?). The first (and main) question is: how should I / could I package this nginx module? I suppose I should patch nginx' APKBUILD in some way, and not try to package it independently, but that leads to corollary questions. What would you advice?
2025-04-26 12:42:29 <rhizoome> mid: you can add nginx to makedepends, so you have complete access to nginx during build. I see there is no third-party nginx-module in alpine, but I found one in arch-linux. They are using nginx-configure etc. so the PKGBUILD might be a good enough template: https://gitlab.archlinux.org/archlinux/packaging/packages/nginx-mod-njs/-/blob/main/PKGBUILD?ref_type=heads
2025-04-26 12:46:47 <mid> hm, the PKGBUILD (make)depends on nginx-src (the nginx source is needed to build a module), which does not seem to exist in Alpine 😞
2025-04-26 13:22:39 <rhizoome> mid: I see there is no nginx-dev. And nginx/APKBUILD contains the "third-party" modules. So in a sense you should add your module nginx/APKBUILD. But I see how this is not great, since you have to rebuild all of nginx if you want to build your module.
2025-04-26 13:26:15 <rhizoome> mid: there are *-src packages in alpine. So you could probably either open an issue, or do merge-request to add that nginx-src package. In either case I cannot say how this will be recived by those in charge.
2025-04-26 13:26:16 <rhizoome> https://pkgs.alpinelinux.org/packages?name=*-src
2025-04-26 13:28:18 <rhizoome> mid: you want to try it locally you could probaby again take nginx-arch package as a template to add a nginx-src subpackage to nginx/APKBUILD
2025-04-26 13:31:58 <qaqland> hi, i think !82591 is ready
2025-04-26 14:15:59 <amf3> @fossdd[m] No worries and thanks for the update. :) 
2025-04-26 14:54:21 <mid> rhizoome: thank you for your advice!, and you're right: I'm going to try to make a nginx-src subpackage, to check first what that would imply… and after that, if successful, of course the maintainer will decide if it is relevant
2025-04-26 19:09:07 <elagost> is it acceptable to depend on gcompat? I've built uptime-kuma into  a package for my own use, andit seems to want to depend on ld-linux. I'm not sure if I could patch that out; don't know much about nodejs and its build processes
2025-04-26 19:11:35 <Ermine> are you trying to package a proprietary program?
2025-04-26 19:12:44 <elagost> no, uptime-kuma is FOSS: https://github.com/louislam/uptime-kuma
2025-04-26 19:12:49 <rhizoome> elagost: that sounds strange. probably not having gcompat installed during build is enough to get rid of that dependency.
2025-04-26 19:13:29 <Ermine> you shouldn't depend on gcompat indeed, it's needed only for proprietary stuff linked against glibc, so you could run it on musl
2025-04-26 19:14:18 <elagost> ok, just ran into some issues with building the package, it did seem to add ld-linux as a 'traced' dependency, but I'm trying again.
2025-04-26 19:14:33 <Ermine> i wonder why does it want gcompat when it's present...
2025-04-26 19:15:40 <Ariadne> probably a build system defect :P
2025-04-26 19:15:40 <Ermine> Does it check for ld-linux during build?
2025-04-26 19:20:22 <elagost> I'm not sure why it would, or at which part. Just says at the end '>>> ERROR: uptime-kuma*: ld-linux-x86-64.so.2: path not found' It builds fine without gcompat but fails packaging. I'm using rootbld.
2025-04-26 19:20:58 <elagost> oh, probably downloading something precompiled as a lot of npm packages are want to do.
2025-04-26 19:21:49 <rhizoome> elagost: an evil build system :-)
2025-04-26 19:22:06 <Ermine> ah, certified npm moment
2025-04-26 19:22:10 <elagost> rhizoome: agreed :)
2025-04-26 19:28:09 <elagost> got it, I was running `npm install` but the actual build runs `npm ci --omit dev`. That one traces fine now and has a smaller package size too.
2025-04-26 19:59:34 <ikke> hmm,
2025-04-26 19:59:36 <ikke> ERROR: Unable to read database state: package file format error
2025-04-26 19:59:38 <ikke> ERROR: Failed to open apk database: package file format error
2025-04-26 19:59:40 <ikke> armv7 / armhf
2025-04-26 20:00:03 <quinq> Out of space?
2025-04-26 20:00:15 <ikke> nope
2025-04-26 20:18:58 <ikke> seems like the triggers file is corrupt
2025-04-27 07:56:06 <maribu> https://git.texlive.info was disabled due to the AI scraper load, which in turn causes texmf-dist builds to fail now :-/
2025-04-27 08:02:54 <mio> maribu: yeah, seeing it during rebuilds, was hoping it would be a temporary situation
2025-04-27 12:27:36 <witcher01> it would be great if someone could look at !75949 :)
2025-04-27 14:56:55 <quinq> Hi
2025-04-27 14:56:59 <quinq> It seems that gajim is borken
2025-04-27 14:57:01 <quinq> $ gajim
2025-04-27 14:57:01 <quinq> Gajim needs python-nbxmpp >= 6.1.0 (found 6.0.2) to run. Quitting...
2025-04-27 15:04:13 <quinq> fossdd[m], did you try to run it?
2025-04-27 15:04:32 <fossdd[m]> !83160
2025-04-27 15:05:05 <quinq> omni, did you? ;p
2025-04-27 15:06:03 <quinq> Are we waiting for Ermine greenlight?
2025-04-27 15:06:16 <quinq> (not sure what's the process)
2025-04-27 15:08:22 <Ermine> sorry for delay, been busy these days
2025-04-27 15:08:35 <Ermine> you have the greenlight
2025-04-27 15:10:40 <quinq> It's Sunday, rest :)
2025-04-27 15:10:54 <quinq> I was just enquiring a bit about who does what
2025-04-27 15:11:51 <quinq> Thanks Ermine 
2025-04-27 15:12:28 <Ermine> but usually i bump gajim and py3-nbxmpp in one merge request
2025-04-27 16:52:02 <jahway603[m]> What is the process for a testing aport to eventually be in the community repo?
2025-04-27 16:52:16 <jahway603[m]> Specifically !83262
2025-04-28 08:26:30 <roxedus-> Is there a better place to see why a build failed for a arch, rather than the build log link which currently 404s?
2025-04-28 08:26:47 <ikke> No
2025-04-28 08:34:45 <roxedus-> The 404 seems to be caused by the package being a subpackage. There's a log available for the package it is derived from. That should be enough for me to work with
2025-04-28 08:36:13 <ikke> Yes, there are no separate logs for subpackages 
2025-04-28 11:05:44 <fossdd[m]> can someone merge !82654?
2025-04-28 11:53:19 <jahway603[m]> What is the process for a testing aport to eventually be part of community?
2025-04-28 12:25:44 <fossdd[m]> if its in testing and a certain amount of testing happend you can open a merge request to move it to community
2025-04-29 00:53:48 <Justin[m]> build-edge-aarch64 seems to be completely stuck, can anyone give it a kick? mono was started on April 22 and lf on April 27.
2025-04-29 00:55:03 <Justin[m]> Sounds like it needs some monitoring to announce in here if a build has taken over x hours.
2025-04-29 06:44:46 <ncopa> rebooted build-edge-aarch64
2025-04-29 06:44:56 <ncopa> i guess the mono build was OOM killed
2025-04-29 06:51:35 <ncopa> im stopping build-edge-aarch64 for now. want to let build-3-22-aarch64 complete mono first. May not have enough memory
2025-04-29 07:11:32 <ikke> ncopa: i killed it
2025-04-29 07:11:49 <ncopa> I also stopped build-3-22-armhf which was building webkitgtk
2025-04-29 07:12:12 <ncopa> im monitoring mono build on build-3-22-aarch64 now
2025-04-29 07:12:39 <ncopa> this will complete
2025-04-29 07:13:12 <ncopa> i hope
2025-04-29 07:13:24 <ikke> Mono also hung the previous time 
2025-04-29 07:13:33 <ikke> It was not OOM
2025-04-29 07:13:37 <ncopa> hum, ok
2025-04-29 07:13:54 <ncopa> yeah, i didnt find any OOM in dmesg
2025-04-29 07:14:47 <ncopa> maybe it will complete if I watch the build logs as it builds :)
2025-04-29 07:16:25 <ikke> Heh
2025-04-29 07:19:34 <ncopa> seems like it passed where it deadlocked last time
2025-04-29 07:20:18 <nu_> yay
2025-04-29 07:24:35 <ncopa> >>> mono: Signing the index...
2025-04-29 07:24:51 <ncopa> yup. it did help to monitor the build :)
2025-04-29 07:27:02 <ncopa> building it on build-edge-aarch64 now
2025-04-29 07:46:33 <ncopa> and it deadlocked
2025-04-29 07:46:36 <ncopa> re-trying
2025-04-29 10:03:46 <Justin[m]> If it deadlocks again, can it be skipped so all the other packages can build, then try again after?
2025-04-29 10:10:52 <ncopa> im trying again a 3rd time
2025-04-29 10:19:19 <ncopa> ok, i thikn i  got it build. re-enabling build-edge-aarch64, build-3-22-aarch64 and build-3-22-armhf
2025-04-29 10:20:01 <ncopa> im gonna bootstrap openjdk on build-3-22-riscv64 now
2025-04-29 10:26:30 <ikke> Justin[m]: skipping would mean disabling it (and anything that depends on it)
2025-04-29 10:26:42 <Justin[m]> Ah
2025-04-29 11:24:43 <fossdd[m]> nothing depends on it, so i'm fine with disabling it for now. but its incredibly annoying since the deadlock wasnt in CI
2025-04-29 11:25:09 <fossdd[m]> in CI it takes 30 mins and thats it idk
2025-04-29 11:26:08 <Habbie> somebody remind me, what's the -s flag for abump for again?
2025-04-29 11:28:08 <ikke> Add CVE details
2025-04-29 11:29:08 <ikke> It adds those to the commit message, not the secfixes list in the APKBUILD itself
2025-04-29 11:49:32 <Habbie> right, thanks
2025-04-29 11:49:36 <Habbie> good start
2025-04-29 12:15:08 <sbraz> Hello, where could I create an issue requesting a modloop with ZFS included? I recently starting using Alpine as a rescue system and it's really great with all the configurable params from mkinitfs, however, I can't use it to rescue systems with ZFS because is is not included in the modules squashfs.
2025-04-29 12:46:34 <Habbie> gitlab appears to be unhappy
2025-04-29 12:46:52 <qaqland> HTTP 502: Waiting for GitLab to boot
2025-04-29 12:46:59 <Habbie> ah, 'waiting for ..' yes
2025-04-29 12:47:04 <Habbie> in 'git' the message is not as clear
2025-04-29 12:48:27 <qaqland> it is back!
2025-04-29 12:51:56 <Habbie> hurray
2025-04-29 12:52:11 <Habbie> 
ACTION immediately overloads it with a big push

2025-04-29 12:57:19 <Habbie> it uhm. does not look 'back'
2025-04-29 13:00:09 <qaqland> 
ACTION :(

2025-04-29 14:28:48 <f_> Habbie: check #alpine-infra
2025-04-29 14:29:04 <f_> > 12:30  <algitbot>  gitlab.alpinelinux.org: [problem] | HTTP(s) gitlab.alpinelinux.org Unreachable | http://dup.pw/a/15556/9201792
2025-04-29 14:29:09 <Habbie> ack
2025-04-29 14:29:29 <f_> > 14:24  <algitbot>  gitlab.alpinelinux.org: [solved] | HTTP(s) gitlab.alpinelinux.org Unreachable | http://dup.pw/a/15556/9201792
2025-04-29 14:29:36 <f_> times in UTC
2025-04-29 14:30:21 <f_> git.a.o has also been having issues but that's not new
2025-04-29 14:30:33 <f_> (AI scrapers overloading it I think)
2025-04-29 14:58:03 <invoked> thought anubis got put on gitlab, no?
2025-04-29 15:02:06 <f_> invoked: git.a.o is Cgit, not gitlab
2025-04-29 15:03:52 <invoked> my bad
2025-04-29 15:17:37 <Habbie> yay i can push
2025-04-29 16:04:21 <f_> \o/
2025-04-29 18:50:14 <raspbeguy> Cicd is still broken
2025-04-29 19:08:12 <ikke> raspbeguy: details?
2025-04-29 19:10:06 <psykose> the failures like `unable to read .cargo-ok file at "/home/buildozer/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/serde-1.0.197/.cargo-ok": stream did not contain valid UTF-8` on the builders look like there was disk corruption and random files are broken
2025-04-29 19:13:37 <raspbeguy> ikke: https://gitlab.alpinelinux.org/raspbeguy/aports/-/jobs/1829496
2025-04-29 19:14:44 <ikke> raspbeguy: thanks, fixed now
2025-04-29 19:15:56 <raspbeguy> ikke: thanks
2025-04-29 19:21:53 <ikke> psykose: that certainly did happen
2025-04-29 19:23:39 <psykose> oof
2025-04-29 19:25:31 <ikke> I've cleaned up the builders
2025-04-30 05:51:32 <ncopa> Good morning!
2025-04-30 05:52:19 <ncopa> PureTryOut: the build-3-21-armhf still has build failures
2025-04-30 05:52:54 <ncopa> i think it it is due to 4f7bc9b70bfc16ee8015b42b495a030e29b0123f
2025-04-30 05:53:21 <ncopa> needs to disable armhf for all packages that depends on qt6-qtdeclarative
2025-04-30 12:42:35 <andypost[m]> Lots of py3 packages are failing on 3.22 builders because of "check" can't start tests - is there general fix or each aport needs own changes? "error: invalid command 'test'"
2025-04-30 16:19:10 <dne> andypost[m]: see issue #17110
2025-04-30 16:41:59 <andypost[m]> dnr: thanks!
2025-04-30 16:44:32 <mio> andypost[m]: the general fix is to call the test runner (pytest, unittest, etc.) directly if possible
2025-04-30 16:45:20 <fossdd[m]> it only happens with setup.py so thats a pretty good time to mass-migrate to gpep517
2025-04-30 16:45:27 <mio> yeah
2025-04-30 16:46:47 <mio> there may be a few cases where the package is old and doesn't switch neatly, not sure yet what the best course of action would be for those
2025-04-30 16:47:34 <fossdd[m]> tbh disabling sounds good if the package is unmaintained upstream
2025-04-30 16:47:40 <fossdd[m]> if nothing depends on it ofc
2025-04-30 16:48:30 <mio> yeah, it may be last resort, to disable check
2025-04-30 16:49:16 <mio> will see how many can be migrated, there are already some that aren't running tests for other reasons
2025-04-30 16:49:17 <fossdd[m]> or the package :)
2025-04-30 16:49:27 <fossdd[m]> i see
2025-04-30 16:49:29 <mio> or that, yes
2025-04-30 17:30:25 <takiama> ello
2025-04-30 17:31:32 <f_> hi
2025-04-30 17:31:40 <fossdd> can somebody merge !83463? :)
2025-04-30 17:33:25 <andypost[m]> ikke: after Gitlab upgrade downstream pipelines are broken because the setting is True after upgrades, use API to set it to false https://docs.gitlab.com/ci/pipelines/merge_request_pipelines/#prevent-pipelines-from-fork-projects
2025-04-30 17:34:22 <andypost[m]> example is https://gitlab.alpinelinux.org/milesalan/aports/-/jobs/1830719
2025-04-30 18:21:30 <ikke> andypost[m]: strange, there was no recent upgrade that could've caused this 
2025-04-30 18:23:03 <ikke> andypost[m]: ci_allow_fork_pipelines_to_run_in_parent_project: true
2025-04-30 18:23:06 <ikke> it's not disabled
2025-04-30 18:24:30 <andypost[m]> ikke: it should be false to allow, faced it twice after upgrade
2025-04-30 18:25:24 <andypost[m]> And new pipelines should be created otherwise updated in db(
2025-04-30 18:25:40 <ikke> andypost[m]: That does not make sense, and it would mean it would be broken for nearly all MRs
2025-04-30 18:26:09 <andypost[m]> I bet it already broken after upgrade
2025-04-30 18:26:25 <ikke> The last upgrade was a couple of weeks ago
2025-04-30 18:26:47 <ikke> No issue with this pipeline: https://gitlab.alpinelinux.org/mio/aports/-/pipelines/320637
2025-04-30 18:27:21 <ikke> So something may be broken, but I'm not sure it's that setting
2025-04-30 18:27:35 <andypost[m]> Hm, the same for my new pipelines... So not clear
2025-04-30 18:30:07 <andypost[m]> ikke: as I see this bug started to appear after 17.10.4 but here it's 17.9 so probably false alert
2025-04-30 18:35:41 <ikke> heh, I found the issue you posted an update in
2025-04-30 18:53:42 <ikke> andypost[m]: it worked after I rebased the branch
2025-04-30 19:37:17 <ikke> andypost[m]: if you learn anything more about this, please let me know
2025-04-30 19:48:36 <andypost[m]> ikke: I learned that gitlab has hidden settings and some changes are not announced like https://gitlab.com/gitlab-org/gitlab/-/merge_requests/182862 
2025-04-30 19:49:15 <andypost[m]> for example drupal.org has stuck for 2 days digging why pipelines did loose access
2025-04-30 19:52:22 <ikke> anoying