2025-07-01 06:37:01 <PureTryOut> algitbot: retry master
2025-07-01 09:57:12 <achill> algitbot: retry master
2025-07-01 16:13:54 <achill> not again..
2025-07-01 16:13:56 <achill> meow
2025-07-01 16:14:11 <achill> i thought it was only vimdoc
2025-07-01 16:14:17 <achill> i'm just gonna downgrade it again
2025-07-01 16:16:09 <achill> i should step away and eat now
2025-07-01 20:37:28 <mio> algitbot: retry master
2025-07-02 01:25:53 <mio> algitbot: retry master
2025-07-02 13:24:19 <achill> algitbot: retry master
2025-07-02 13:26:17 <achill> clicks on log -> 404, nice
2025-07-02 13:26:24 <achill> hmm
2025-07-02 13:28:57 <achill> algitbot: retry master
2025-07-02 16:42:39 <andypost[m]> algitbot: retry master
2025-07-02 18:15:02 <achill> algitbot: retry master
2025-07-02 18:49:50 <andypost[m]> algitbot: retry master
2025-07-03 15:31:31 <achill> algitbot: retry master
2025-07-03 21:50:56 <achill> oh come on
2025-07-03 21:51:10 <achill> algitbot: retry master
2025-07-06 09:10:06 <achill> algitbot: retry master
2025-07-07 07:39:20 <achill> algitbot: retry master
2025-07-07 10:17:05 <achill> algitbot: retry 3.22-stable
2025-07-09 10:37:55 <achill> algitbot: retry master
2025-07-09 12:41:18 <achill> algitbot: retry master
2025-07-09 12:47:34 <achill> algitbot: retry master
2025-07-09 13:41:28 <achill> algitbot: retry master
2025-07-09 15:56:39 <ikke> algitbot: retry master
2025-07-09 16:05:57 <ikke> algitbot: retry master
2025-07-09 16:08:52 <achill> algitbot: retry master
2025-07-09 16:23:57 <achill> algitbot: retry master
2025-07-09 16:44:33 <ikke> algitbot: retry master
2025-07-09 16:46:02 <ikke> nmeum: kubernetes fails with /usr/lib/gcc/aarch64-alpine-linux-musl/14.3.0/../../../../aarch64-alpine-linux-musl/bin/ld.gold: --no-dynamic-linker: unknown option
2025-07-09 16:55:38 <ikke> same with k3s
2025-07-09 16:57:56 <achill> algitbot: retry master
2025-07-09 17:23:58 <ikke> Is it expected that go depends on binutils on certain aches?
2025-07-09 17:24:00 <ikke> arches*
2025-07-09 17:24:59 <ikke> yup, explicitly in the APKBUILD
2025-07-09 17:43:20 <achill> ikke: at one point, we'd have to get rid of gold anyway since its unmaintained upstream and binutils wants to remove it from their repo
2025-07-09 17:44:20 <achill> i'm trying to reproduce the issue on my s390x vm
2025-07-09 17:57:08 <achill> algitbot: retry master
2025-07-09 20:29:57 <achill> algitbot: retry master
2025-07-09 21:02:12 <achill> algitbot: retry master
2025-07-10 05:00:30 <mio> algitbot: retry master
2025-07-10 13:39:39 <achill> yeah idk go with PIE on s390x is screwed up
2025-07-10 13:39:47 <achill> its always getting _cgo_pthread_key_created missing
2025-07-10 13:40:20 <achill> idk if it even produced a single working binary with PIE
2025-07-10 13:41:19 <ikke> achill: maybe we should get IBM involved?
2025-07-10 13:42:10 <achill> yeah maybe
2025-07-10 13:42:15 <achill> i think https://gitlab.alpinelinux.org/alpine/aports/-/issues/17271 could be related
2025-07-10 19:08:08 <achill> guess i'll diable PIE for docker-auth and argocd
2025-07-10 19:08:37 <achill> incredibly annoyig that ths is only discoverable at runtime
2025-07-10 19:40:08 <ikke> algitbot: retry master
2025-07-10 19:58:40 <ikke> ncopa: did you mean to push that to 3.22?
2025-07-10 19:59:49 <ikke> (edge does not have it, and pkgrel skips one)
2025-07-10 20:02:02 <achill> i guess because !86980's ci didnt finish yet
2025-07-10 20:14:49 <ncopa> yeah
2025-07-10 20:15:27 <ncopa> the edge MR took longer time because it now builds the cross targets
2025-07-10 20:16:01 <ncopa> i saw the skip or -r1 but decided to just go with it. its just a number
2025-07-10 20:16:20 <ncopa> that way 2.44-r2 has the fix, regardless of branch
2025-07-10 20:16:49 <ncopa> im sort of disapointed
2025-07-10 20:16:58 <ncopa> i cannot see how it can be exploited
2025-07-10 20:17:20 <ncopa> you would need to first exploit gcc to spit out a malicious binary
2025-07-10 20:17:26 <achill> like basically 90% of the cves
2025-07-10 20:17:39 <achill> "theoretical dos" bla bla bla
2025-07-10 20:17:39 <ncopa> yeah
2025-07-10 20:17:53 <ncopa> the other objdump is a memleak, in a short tunning program
2025-07-10 20:18:07 <ncopa> also theoretical DOS
2025-07-10 20:18:25 <ikke> THe problem is when they manage to combine multiple theoretical vulnerabilies 
2025-07-10 20:18:39 <ncopa> that said, never underestimate the creativity of the dark side
2025-07-10 20:18:40 <ncopa> yeah
2025-07-10 20:18:46 <ncopa> so i think its good to fix them
2025-07-10 20:18:52 <achill> yeah i guess so
2025-07-10 20:20:08 <ncopa> ikke: thanks for being alert though
2025-07-10 20:20:26 <ncopa> i *am* tired and I almost pushed somethign from wrong terminal window
2025-07-10 20:20:48 <ncopa> I think the CVE fix is somewhat incomplete though
2025-07-10 20:21:04 <ikke> In the issue there were multiple commits involved
2025-07-10 20:21:09 <ikke> one for ld, one for the rest
2025-07-10 20:21:13 <ncopa> yeah
2025-07-10 20:21:24 <ncopa> i only grabbed the one for ld
2025-07-10 20:21:33 <ncopa> *shrug*
2025-07-10 20:22:01 <ncopa> the CVE only mentions the first commit
2025-07-10 20:22:14 <ncopa> so soon we will have a follow-up CVE with the second
2025-07-10 20:23:37 <ikke> ncopa: maye we should use the `tag:help-wanted` label more often
2025-07-10 20:24:03 <ncopa> maybe
2025-07-10 20:24:04 <achill> possibly yeah
2025-07-10 20:24:24 <ncopa> but I think the reporter would not have the tech skills to fix it properly
2025-07-10 20:24:32 <ncopa> I *dont* think
2025-07-10 20:24:47 <ncopa> it involved a cherry-pick conflict
2025-07-10 20:24:56 <ikke> It does not mean the reported would need to do it
2025-07-10 20:25:00 <ikke> reporter*
2025-07-10 20:25:03 <ncopa> true
2025-07-10 20:25:25 <ncopa> but I doubt anyone with the needed skills would care
2025-07-10 20:25:58 <ncopa> anyway, i think someone owes me a beer now
2025-07-10 20:26:45 <ncopa> and there are some satisfaction in seeing the dashboard show everythign green on Alpine while red on all other distros :)
2025-07-10 20:26:52 <ikke> :)
2025-07-10 20:26:56 <achill> hehe
2025-07-10 20:27:20 <ikke> 
ACTION prods security.a.o

2025-07-10 20:27:42 <achill> i have http://build.alpinelinux.org/ on one of my monitors and hope for days that at somepoint all builders are idle again
2025-07-10 20:28:07 <ikke> aarch64 is currently unavailable :(
2025-07-10 20:28:17 <achill> yeah so ive heard
2025-07-10 20:28:35 <achill> but i feel like riscv64 will still be slower
2025-07-11 08:45:08 <achill> wut
2025-07-11 15:13:25 <ikke> algitbot: retry master
2025-07-11 15:16:15 <ikke> algitbot: retry master
2025-07-11 19:52:48 <nmeum> oops
2025-07-12 15:51:20 <achill> algitbot: retry master
2025-07-12 21:42:39 <achill> * algitbot: retry master
2025-07-13 19:38:48 <achill> algitbot: retry master
2025-07-13 20:59:00 <achill> algitbot: retry master
2025-07-13 21:06:42 <achill> algitbot: retry 3.22-stable
2025-07-13 21:24:50 <achill> urgh looks like i do have to disable revdeps temporarily
2025-07-13 21:35:14 <achill> no the loongarch error is unrelated i think
2025-07-14 12:53:03 <achill> algitbot: retry master
2025-07-14 18:45:22 <achill> oh no what now
2025-07-14 19:24:32 <ncopa> algitbot retry master
2025-07-14 19:24:38 <ncopa> algitbot: retry master
2025-07-14 21:06:03 <achill> algitbot: retry master
2025-07-14 21:07:13 <achill> and another package missing
2025-07-14 21:14:32 <achill> but this one doesnt look like something i like having
2025-07-14 21:16:57 <achill> https://github.com/python-poetry/poetry/commit/8a1ed35a12bd7587f2878071f0a476ceb1e133fb
2025-07-14 21:17:12 <achill> seems like it wont have a affect on our packages, but still dunno how much itll even work
2025-07-14 21:17:16 <achill> aaaa
2025-07-14 21:46:05 <achill> idk im gonna package it, but just so poetry is satisfied. i dont expect it to properly work
2025-07-14 21:47:35 <achill> !87200
2025-07-15 07:59:48 <achill> what now
2025-07-15 07:59:59 <achill> algitbot: retry master
2025-07-15 08:20:47 <achill> algitbot: retry master
2025-07-15 08:29:59 <achill> how hard can it be to tell the cpu some instructions and dont segfault aaaa
2025-07-15 08:30:06 <achill> algitbot: retry master
2025-07-15 09:01:47 <achill> * algitbot: retry master
2025-07-15 09:04:00 <achill> * algitbot: retry master
2025-07-15 09:58:03 <achill> algitbot: retry master
2025-07-15 20:34:50 <achill> algitbot: retry master
2025-07-15 20:35:11 <achill> loongarch64 if you finish testing/ before i got to bed, you deserve a hug
2025-07-15 20:35:22 <achill> so better hurry up
2025-07-15 20:37:16 <ikke> still 3 packages to go
2025-07-15 20:40:00 <ikke> last one
2025-07-15 20:41:10 <ikke> \o/
2025-07-15 20:41:18 <ikke> Testing
2025-07-15 20:41:22 <ikke> oh, 14 packages
2025-07-15 20:41:24 <ikke> that's a bit more
2025-07-15 20:46:01 <achill> but 14 is manageable too
2025-07-15 21:04:55 <achill> o/
2025-07-16 13:55:12 <achill> algitbot: kick build-edge-s390x
2025-07-16 21:41:19 <achill> urgh
2025-07-17 09:57:45 <achill> i guess no we have to disable quite a few revdeps of qtwebengine 🙃
2025-07-17 11:02:27 <PureTryOut> achill: oh, woops. Didn't think of that... Ugh
2025-07-17 11:02:43 <PureTryOut> The loongarch64 person did say they're working on fixing qtwebengine but I haven't seen anything yet
2025-07-17 11:42:35 <achill> <PureTryOut> achill: oh, woops. Didn't think of that... Ugh
2025-07-17 11:42:35 <achill> i mean its inevitable, dont think delaying upgrades for that makes a lot sense
2025-07-17 16:37:05 <PureTryOut> algitbot: retry master
2025-07-17 17:28:05 <achill> aaaaaaaaaaaaaaaaaaaaaa
2025-07-17 17:30:59 <achill> wut
2025-07-17 17:31:10 <achill> i thought that was fixed
2025-07-17 17:31:21 <achill> 
ACTION should test more

2025-07-17 17:32:53 <achill> enough internet for today
2025-07-18 07:11:16 <achill> oh thats a lot
2025-07-18 19:17:47 <mio> algitbot: retry master
2025-07-18 19:37:18 <mio> algitbot: retry master
2025-07-18 21:02:16 <mio> algitbot: retry master
2025-07-19 14:14:32 <weechat11k> https://filehost.0bin.xyz/FgyiRqcs4b20.zip
2025-07-19 14:18:38 <weechat11k> commited?
2025-07-21 17:40:53 <ikke> algitbot: retry master
2025-07-21 17:45:37 <mio> algitbot: retry 3.22-stable
2025-07-21 17:46:22 <ikke> mio: thanks ^_^
2025-07-21 17:46:47 <mio> :)
2025-07-21 18:29:10 <mio> algitbot: retry 3.22-stable
2025-07-21 18:38:51 <mio> algitbot: retry 3.22-stable
2025-07-21 18:45:26 <mio> algitbot: retry 3.22-stable
2025-07-22 00:32:44 <mio> algitbot: retry 3.22-stable
2025-07-22 09:34:30 <achill> ncopa: i guess the error comes from 8f0a949bce597b1e9174a81e3bab560b768e28a6
2025-07-22 10:45:08 <ncopa> ok. lets revert that
2025-07-22 16:28:27 <achill> cc raspbeguy <https://matrix.to/#/%40oftc_raspbeguy%3Apostmarketos.org>
2025-07-22 16:28:31 <achill> idk if its just flaky
2025-07-22 16:28:36 <achill> algitbot: retry master
2025-07-22 17:44:47 <raspbeguy> achill: it was building fine on the PR
2025-07-22 18:23:18 <achill> <raspbeguy> achill: it was building fine on the PR
2025-07-22 18:23:18 <achill> seems like it passed now
2025-07-22 18:23:39 <achill> flaky tests are annoying, espeially 5x in a row
2025-07-22 18:23:51 <achill> feel free to disable them on the next uprade or something
2025-07-22 20:00:59 <achill> urgh that wouldve been nice in a second line or something
2025-07-22 20:05:48 <ikke> ahuh
2025-07-22 20:14:21 <achill> 13:01.00 error: failed to mmap file '/home/buildozer/aports/community/firefox/src/firefox-140.0.4/obj/armv7-alpine-linux-musleabihf/release/deps/libstyle-cfd123a59c944b7e.rlib': Out of memory (os error 12)
2025-07-22 20:23:49 <ikke> achill: 32-bits address space limit?
2025-07-22 20:24:54 <achill> 🤷maybe
2025-07-22 20:25:42 <achill> it worked in ci
2025-07-22 21:36:02 <achill> algitbot: retry master
2025-07-22 22:05:49 <achill> oh come on gnu
2025-07-22 22:05:52 <achill> do one thing right
2025-07-23 02:53:43 <mio> algitbot: retry 3.22-stable
2025-07-23 03:51:17 <mio> algitbot: retry master
2025-07-23 04:10:55 <mio> algitbot: retry 3.22-stable
2025-07-23 07:50:01 <achill> cc Ariadne <https://matrix.to/#/%40oftc_Ariadne%3Apostmarketos.org>
2025-07-23 08:46:01 <achill> algitbot: retry master
2025-07-23 16:08:45 <ikke> out-of-memory on 32-bits :/
2025-07-23 16:10:25 <mio> is there any way to have them build one at a time? e.g. only one arch at a time
2025-07-23 16:10:30 <mio> not sure if it would help
2025-07-23 16:10:45 <ikke> It's not that the server is oom
2025-07-23 16:11:05 <ikke> 113G of memory free
2025-07-23 16:11:20 <ikke> It's that 32-bits processes cannot allocate more than 4G of memory
2025-07-23 16:11:37 <mio> ah, like addressable memory
2025-07-23 16:11:41 <ikke> yes, exactly
2025-07-23 16:12:49 <ikke> That's why only 32-bits arches are affected
2025-07-23 16:14:54 <mio> okay. was thinking of it as firefox oom-ed on 3.22 armv7 previously, but seemed to resolve itself after another rust aport completed
2025-07-23 16:15:07 <mio> guess no such luck here
2025-07-23 16:16:10 <mio> would reducing cores used reduce memory allocated at time?
2025-07-23 16:17:04 <mio> s/at time/in the process/
2025-07-23 16:17:04 <ikke> I don't think in this case. It's trying to embed static assets
2025-07-23 16:20:51 <mio> wonder if it builds with a different configuration in ci
2025-07-23 16:57:00 <ikke> `go generate --tags bindata .` in modules/options on the builder triggers it
2025-07-23 16:57:06 <ikke> Trying in docker now
2025-07-23 17:02:23 <ikke> The generated bindata.go is 'just' 10M
2025-07-23 17:15:45 <ikke> mio: I have a feeling we're hitting some bug
2025-07-23 17:17:20 <ikke> The shell output is behaving weirdly when it crashes even
2025-07-23 17:18:03 <mio> ouch
2025-07-23 17:20:07 <mio> was looking at upstream repo, there was a change last month to generate-bindata.go, but probably unrelated https://codeberg.org/forgejo/forgejo/pulls/8176
2025-07-23 17:20:51 <ikke> maybe the last line
2025-07-23 17:21:01 <mio> though L127 seemed interesting
2025-07-23 17:21:07 <ikke> exactly
2025-07-23 17:23:40 <ikke> mio: that seems to be it
2025-07-23 17:23:43 <ikke> let me verify
2025-07-23 17:24:17 <mio> okay
2025-07-23 17:30:05 <ikke> yeah, reverting that line makes it build
2025-07-23 17:30:22 <ikke> The question is why zstd.SpeedBestCompression is resulting in corruption
2025-07-23 17:31:28 <ikke> And do we want to revert that only on arm*?
2025-07-23 17:36:20 <mio> from the upstream tickets, sounds like it was originally introduced to speed up compression https://codeberg.org/forgejo/forgejo/pulls/8143
2025-07-23 17:36:59 <mio> but then a bug was found on armhf/armv7
2025-07-23 17:37:48 <mio> https://codeberg.org/forgejo/forgejo/issues/8165#issuecomment-5110002
2025-07-23 17:38:50 <mio> but subsequently they were able to switch to native generation of bindata instead of emulated
2025-07-23 17:39:12 <mio> not sure how they resolved the issue
2025-07-23 17:39:18 <ikke> But, we're not emulating either
2025-07-23 17:39:37 <mio> right, that was the initial workaround
2025-07-23 17:39:55 <ikke> ah ok
2025-07-23 17:41:34 <mio> so guess in short, not sure if they found a satisfactory solution to zstd.SpeedBestCompression, but it does seem to be a known issue
2025-07-23 17:42:36 <ikke> But apparently not reported upstream?
2025-07-23 17:43:31 <mio> yeah, maybe not
2025-07-23 17:44:07 <ikke> Don't see anything here: https://github.com/klauspost/compress/issues?q=is%3Aissue
2025-07-23 17:49:19 <ikke> And I wonder why it's not triggered in docker
2025-07-23 17:57:46 <mio> don't know about ci, in upstream it seems like there's FORGEJO_GENERATE_SKIP_HASH set that skips generating the bindata if the file already exists
2025-07-23 18:01:54 <ikke> mio: I believe that's not relevant in our case
2025-07-23 18:02:50 <mio> okay. wasn't sure if they pre-generate the bindata for their ci to help mitigate the issue
2025-07-23 18:03:16 <ikke> they might
2025-07-23 18:04:22 <mio> of course that doesn't resolve the original question of why the zstd.SpeedBestCompression method would fail
2025-07-23 18:06:28 <ikke> Do we want to report it upstream (to klauspost)?
2025-07-23 18:06:41 <ikke> Would be good to have a reproducer though
2025-07-23 18:13:35 <ikke> I can reproduce it in my personal container at least
2025-07-23 18:18:00 <mio> it would probably be good to notify upstream ... any thoughts what to do about the package in the meantime?
2025-07-23 18:25:38 <ikke> It's not deterministic
2025-07-23 18:26:17 <ikke> It's encoding a list of files, but it does not fail after the same file each time
2025-07-23 18:44:26 <ikke> mio: I suppose reverting the change, either try to do it for those 2 arches, or for all arches
2025-07-23 18:46:19 <mio> okay ... maybe just the arches where this is an issue?
2025-07-23 18:46:31 <ikke> means we have to manually apply the patch
2025-07-23 18:48:38 <mio> okay ... whichever you or maintainer think is best
2025-07-23 19:01:13 <ikke> Testing a commit now before making an MR
2025-07-23 19:06:03 <ikke> !87694
2025-07-23 19:12:16 <mio> :)
2025-07-23 20:29:33 <ikke> The retrying does become a bit anoying
2025-07-25 18:27:00 <Ariadne> actually
2025-07-25 18:34:16 <achill> algitbot: retry master
2025-07-25 18:35:58 <ikke> algitbot: retry master
2025-07-25 18:37:03 <ikke> Ariadne: the x86 failure was not me btw
2025-07-25 18:37:19 <ikke> adaint.h:324:8: error: unknown type name 'cpu_set_t'
2025-07-25 18:37:33 <ikke> Oh, that's part of configure
2025-07-25 18:46:31 <Ariadne> ikke: yeah i have a fix for that already.  i thought it was redundant so i didn't include it :P
2025-07-26 10:28:29 <Ariadne> algitbot: retry master
2025-07-26 11:10:13 <Ariadne> algitbot: retry master
2025-07-26 11:26:31 <Ariadne> algitbot: retry master
2025-07-26 11:28:49 <Ariadne> weird, something seems to be up with build.alpinelinux.org
2025-07-26 11:30:08 <Ariadne> s390x and x86 builds are completed, but build.a.o doesn't reflect that
2025-07-26 13:59:36 <ikke> Ariadne: I did reboot the server hosting msg.a.o, possible related
2025-07-26 13:59:40 <ikke> algitbot: retry master
2025-07-26 14:02:02 <ikke> algitbot: retry 3.22-stable
2025-07-26 14:02:08 <ikke> algitbot: retry 3.21-stable
2025-07-26 14:02:14 <ikke> algitbot: retry 3.20-stable
2025-07-26 14:02:17 <ikke> algitbot: retry 3.19-stable
2025-07-27 13:08:19 <ikke> algitbot: retry master
2025-07-28 22:02:27 <achill> algitbot: retry master
2025-07-29 15:35:17 <ikke> libbpf.c:10021:33: error: 'mod_len' may be used uninitialized [-Werror=maybe-uninitialized]
2025-07-29 15:35:19 <ikke> 10021 |                 if (mod_name && strncmp(mod->name, mod_name, mod_len) != 0)
2025-07-29 23:07:42 <andypost[m]> algitbot: retry master
2025-07-29 23:33:15 <andypost[m]> algitbot: retry master
2025-07-30 13:55:28 <achill> cc andypost[m] <https://matrix.to/#/%40oftc_andypost%5Bm%5D%3Apostmarketos.org>
2025-07-30 14:04:25 <andypost[m]> achill: thanks disabling test
2025-07-30 14:10:37 <andypost[m]> achill: I can't get what's vary with glob() in CI and builders... better to keep a test disabled
2025-07-30 14:27:02 <andypost[m]> algitbot: retry master
2025-07-30 15:17:29 <andypost[m]> algitbot: retry master
2025-07-31 13:47:34 <achill> urgh didnt expect that
2025-07-31 13:47:57 <ikke> :-/
2025-07-31 13:50:12 <ikke> algitbot: retry master
2025-07-31 13:52:15 <achill> algitbot: retry master
2025-07-31 13:53:16 <achill> algitbot: retry master
2025-07-31 14:03:27 <achill> algitbot: retry master
2025-07-31 14:07:09 <achill> wut