2024-02-01 00:03:29 <andypost[m]> algitbot: retry master
2024-02-01 00:30:08 <andypost[m]> algitbot: retry master
2024-02-01 00:33:35 <andypost[m]> algitbot: retry master
2024-02-01 00:47:58 <omni> algitbot: retry master
2024-02-01 00:55:12 <andypost[m]> algitbot: retry master
2024-02-01 23:01:32 <ikke> algitbot: retry 3.19-stable
2024-02-02 16:17:25 <omni> cely: that's toxic
2024-02-03 16:47:46 <omni> algitbot: retry master
2024-02-03 17:10:03 <omni> algitbot: retry master
2024-02-04 11:47:22 <ikke> Ariadne: from config.log: https://tpaste.us/qE84 
2024-02-04 11:47:54 <Ariadne> i have fixed it
2024-02-04 11:49:23 <Ariadne> 
ACTION mutters things about '#!/usr/bin/sh'

2024-02-04 11:49:48 <Ariadne> algitbot: retry master
2024-02-04 12:52:33 <omni> algitbot: retry master
2024-02-04 18:36:02 <ikke> algitbot: retry master
2024-02-04 18:37:55 <ikke> algitbot: retry 3.19-stable
2024-02-04 18:37:58 <ikke> algitbot: retry 3.18-stable
2024-02-04 18:38:01 <ikke> algitbot: retry 3.17-stable
2024-02-04 18:38:04 <ikke> algitbot: retry 3.16-stable
2024-02-05 03:12:36 <celie> algitbot: retry master
2024-02-05 05:34:31 <omni> algitbot: retry master
2024-02-05 11:18:35 <ikke> "add support for --quiet to only print pkgname" \o/
2024-02-05 11:45:27 <ikke> Non-zero exit status: 255
2024-02-05 11:45:29 <ikke>   Parse errors: No plan found in TAP output
2024-02-05 11:45:32 <ikke> celie: ^
2024-02-05 11:52:28 <celie> ikke: i'm sorry, i don't know what's causing that
2024-02-05 11:52:34 <celie> it passed in the CI
2024-02-05 11:53:18 <ikke> yeah, puzzled as well
2024-02-05 11:54:51 <celie> algitbot: retry master
2024-02-05 12:02:04 <celie> I wonder if `make -j1 test` will solve it
2024-02-05 13:16:50 <omni> but it's before that , right?
2024-02-05 13:17:17 <omni> failed to rename lockfile to '/home/buildozer/.gitconfig': Operation not permitted at t/01-repo.t line 18t/01-repo.t .................
2024-02-05 13:18:01 <omni> is the first thing that differ on any of the architectures where it's failing to those where it's not
2024-02-05 13:18:41 <omni> on armv7:
2024-02-05 13:18:43 <omni> t/01-repo.t ................. ok
2024-02-05 13:48:21 <celie> Yeah, i guess those .gitconfig's don't have main as their default branch (which is what line 18 is dealing with)
2024-02-05 13:52:13 <celie> i wonder if the CI runners have a ~/.gitconfig. i have it (with main as init default branch), and 01-repo.t passes for me locally
2024-02-05 14:07:09 <celie> Anyway, the "failed to rename lockfile" error seems to be coming from libgit2, so i think it's best to just disable tests for now (!60262) and when i find the time, i'll try running tests locally with different .gitconfig's to see what triggers that error
2024-02-05 14:41:29 <omni> sorry for stalling but I'd like to get it sorted
2024-02-05 14:41:46 <celie> omni: if you want, you can try `make -j1 tests` to see if it fixes the other errors
2024-02-05 14:43:15 <omni> yeah, I'll do that
2024-02-05 14:43:48 <celie> Thanks
2024-02-05 14:44:31 <ptrc> omni: can you try doing `export HOME=$builddir/home; export GIT_CONFIG_NOSYSTEM=1; git config --global init.defaultBranch main` in the tests? or something to that extent
2024-02-05 14:44:53 <ptrc> or well, mostly the first two
2024-02-05 14:52:22 <omni> ptrc: in !60270 ?
2024-02-05 14:52:47 <ptrc> i mean, the tests pass on CI anyway, don't they?
2024-02-05 14:55:06 <celie> hopefully -j1 solves the test_repo issue, and the environment variables solve the .gitconfig issue
2024-02-05 14:56:00 <celie> anyway, i don't think it's really necessary to run the riscv64 CI since it's already built successfully, and the builders don't run tests anyway
2024-02-05 15:00:47 <celie> omni: could you merge the -j1 change first? i want to see if that will fix the test_repo issue
2024-02-05 15:04:09 <omni> celie: ah, tests aren't run on the riscv64 package builder, right?
2024-02-05 15:04:18 <celie> Yes
2024-02-05 15:06:25 <omni> one of these days, when there's nothing else to do, I'd like to go through all the aports and enable all the tests and upstream all the patches
2024-02-05 15:07:08 <omni> ok, that wasn't it
2024-02-05 15:07:54 <celie> Hmm, ok, so maybe try the 2 environment variables then
2024-02-05 15:08:34 <omni> just in check() or earlier and outside?
2024-02-05 15:09:07 <celie> i think just in check() would be good enough
2024-02-05 15:09:49 <ptrc> yeah, just in check would be enough
2024-02-05 15:13:16 <omni> like so? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/60274/diffs
2024-02-05 15:14:20 <celie> Yes, but you'll probably have to quote "$builddir"
2024-02-05 15:15:04 <celie> Ah, now tests are failing in CI too
2024-02-05 15:15:20 <omni> progress
2024-02-05 15:15:35 <celie> Maybe you need to mkdir "$builddir"/home
2024-02-05 15:17:10 <omni> but "failed to create locked file" rather than "failed to rename lockfile to"...
2024-02-05 15:18:13 <celie> Actually, i think i would prefer $HOME to be just "$srcdir" unless it there's a reason not to do so
2024-02-05 15:18:17 <omni> why "/home" though?
2024-02-05 15:18:26 <omni> yeah...
2024-02-05 15:21:31 <omni> uhm, other error
2024-02-05 15:21:49 <celie> Did it just fix the tests but break abuild
2024-02-05 15:22:43 <omni> not sure if it fixed the tests as they only fail on those three package builders, but yeah
2024-02-05 15:23:20 <celie> Maybe try `make HOME="$srcdir"` test or `HOME="$srcdir" make test`
2024-02-05 15:23:33 <celie> `make HOME="$srcdir" test`
2024-02-05 15:23:48 <celie> *
2024-02-05 15:32:07 <omni> should I just pass both variables on the make test line? 
2024-02-05 15:33:32 <celie> Maybe i would like to try it without the GIT_CONFIG_NOSYSTEM export, i tried it locally, and setting HOME in `make` was enough to make it create a .gitconfig in the new $HOME
2024-02-05 15:33:33 <omni> I'm tempted to try without $GIT_CONFIG_NOSYSTEM to see if setting $HOME during the tests is enough
2024-02-05 15:33:43 <celie> :)
2024-02-05 15:33:48 <omni> ok, let's do that first then
2024-02-05 15:37:55 <celie> It worked
2024-02-05 15:37:58 <celie> Thanks a lot :)
2024-02-05 15:39:49 <celie> So, i guess the 2 error messages were related, probably the tests looked for the 'master' branch (or whatever was in the builders' ~/.gitconfig) in test_repo and couldn't find it
2024-02-05 15:40:16 <omni> \o/
2024-02-05 15:52:26 <celie> omni: i just tried it out locally, and the tests restore the old value of default branch when they complete (i aborted the tests half way through and 'main' that they set was left there)
2024-02-05 15:53:24 <celie> So, i'm guessing the builders that failed the tests were the ones that didn't allow ~/.gitconfig to be modified and didn't already have main as the default branch
2024-02-05 16:04:31 <omni> ikke: I have this idea that you know the most about how the builders are set up
2024-02-05 16:06:56 <ikke> there is no special rights on ~/.gitconfig, but build systems also have no business in modifying it
2024-02-05 21:55:08 <nmeum> oh oh
2024-02-05 21:55:21 <nmeum> algitbot: retry master
2024-02-05 22:10:21 <omni> algitbot: retry master
2024-02-05 23:04:26 <ptrc> algitbot: retry master
2024-02-05 23:04:29 <ptrc> please work
2024-02-05 23:04:58 <ptrc> aw
2024-02-05 23:16:36 <andypost[m]> ptrc: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/59838#note_375289
2024-02-05 23:18:15 <ptrc> ooh, okay
2024-02-06 09:37:18 <cely> Hmm, apparently the ARM builders are faster than the CI runners
2024-02-06 09:59:44 <cely> ptrc: Perhaps you could try with half a patch, stop patching the files in compiler/*, but keep the patch for library/*
2024-02-06 10:00:10 <cely> That would probably mean it would need yet another rebuild to get the patch into library/*
2024-02-06 10:00:30 <cely> or rather, get the patch out of library/*
2024-02-06 10:00:31 <cely> hehe
2024-02-06 10:06:42 <cely> i think LLVM 17 is faster, so hopefully that's reflected in the rebuilds too
2024-02-06 10:10:12 <cely> Hmm, but coming to think about it once the intrinsics have been added back to the compiler, we might as well try to upgrade to Rust 1.74, instead of rebuilding 1.73 yet again
2024-02-06 10:57:46 <omni> I need to catch up...
2024-02-06 11:01:54 <cely> i think it's mostly confirmed, half a patch works
2024-02-06 11:02:13 <cely> and all the archs besides riscv64 have Rust 1.73.0
2024-02-06 11:03:06 <omni> so llvm17 didn't work to build 1.73.0?
2024-02-06 11:03:24 <cely> No, LLVM 17 will work
2024-02-06 11:03:36 <omni> but llvm16 was used
2024-02-06 11:03:52 <cely> Yes, that's why we have !60295
2024-02-06 11:04:39 <cely> and i've tried it out, just remove the patch for compiler/* and keep library/* patched
2024-02-06 11:04:47 <cely> and the CI should succeed
2024-02-06 11:05:26 <cely> After that we either rebuild again the the patch completely removed, or try our luck with 1.74
2024-02-06 11:05:30 <omni> ok
2024-02-06 11:05:35 <cely> s/the//
2024-02-06 11:05:44 <cely> with the*
2024-02-06 11:06:36 <omni> I don't know how important it is to bump _bootver but from memory it looked like it used to be bumped to the version being upgraded from
2024-02-06 11:06:51 <cely> This time it is probably necessary
2024-02-06 11:06:51 <omni> until the last couple of upgrades
2024-02-06 11:07:23 <cely> to make it clear that we want 1.73 to build 1.73
2024-02-06 11:08:08 <cely> (Of course, 1.72 has probably been removed from the apk index, but still, better to be safe)
2024-02-06 11:12:15 <omni> ah, so _bootver=1.73.0 even?
2024-02-06 11:12:49 <omni> it's used in $makedepends_build
2024-02-06 11:13:00 <omni> cargo-bootstrap=>$_bootver
2024-02-06 11:13:02 <omni> rust-bootstrap>=$_bootver
2024-02-06 11:13:21 <omni> why do they differ? => vs >=
2024-02-06 11:13:42 <cely> Ah
2024-02-06 11:13:52 <cely> You caught a typo :)
2024-02-06 11:14:40 <omni> right?
2024-02-06 11:15:07 <cely> >= is the right one
2024-02-06 11:15:13 <omni> thought so
2024-02-06 11:28:34 <ikke> cely: CI for ARM runs in qemu
2024-02-06 11:33:05 <cely> Oh ok
2024-02-06 11:33:22 <cely> Thanks for telling me, didn't know that
2024-02-06 11:40:54 <cely> omni: perhaps you could update !60295? maybe Patrycja wouldn't mind, i think probably squashing the typo fix into the current commit, and adding one of your own updating the patch
2024-02-06 11:41:27 <cely> i kind of want to minimize any aport potentially getting built with that patch in effect..
2024-02-06 11:42:39 <cely> and since it looks like it was only needed to do the 1.73 upgrade, and can be removed, probably the sooner that's done the better
2024-02-06 11:48:34 <omni> one of my own updating the patch?
2024-02-06 11:49:54 <cely> add a commit from you to the MR doing that?
2024-02-06 11:50:33 <cely> i mean, updating the patch to remove the patched files under compiler/*
2024-02-06 11:50:35 <omni> ah, I thought that was implied =)
2024-02-06 11:53:01 <omni> ptrc: did we push at the same time?
2024-02-06 11:53:05 <omni> sorry about that
2024-02-06 11:54:46 <cely> Whoops, did that confuse Gitlab?
2024-02-06 11:57:59 <ikke> cely: what?
2024-02-06 11:59:29 <cely> Pushing at the same time
2024-02-06 12:22:46 <omni> cely: https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1267787
2024-02-06 12:23:11 <omni> I retriggered the x86_64 pipeline and it failed
2024-02-06 12:28:14 <cely> omni: That's what i've been trying to say, it still needs half a patch :)
2024-02-06 12:28:49 <cely> We need to add the intrinsics back to the compiler first while keeping them out of the library
2024-02-06 12:29:19 <omni> ah
2024-02-06 12:29:27 <cely> and in the next iteration, if nothing unexpected turns up, we remove the patch completely, so the instrinsics are back in the library as well
2024-02-06 12:29:36 <omni> maybe I should make some coffee...
2024-02-06 12:36:40 <cely> i wonder if it will be possible to do everything in Rust 1.74: switch to LLVM, and add the intrinsics back to compiler
2024-02-06 12:42:27 <cely> nope, probably not doable, they've removed some of the bootstrap fallbacks, so they're assuming you already have those intrinsics
2024-02-06 12:55:19 <cely> i think we do need to undo half of the patch, otherwise this delicate dance between the versions will not work
2024-02-06 13:12:55 <cely> omni: that looks right, and should get the MR to build, i'm currently trying to see if Rust 1.74 will build with the Rust 1.73 with the patch half undone (so we don't need to rebuild 1.73 yet again and can jump straight to 1.74 for putting the intrinsics back into the library)
2024-02-06 13:18:54 <omni> 👍
2024-02-06 13:19:29 <omni> maybe I should have a look at our other patches
2024-02-06 13:25:20 <cely> i'm actually looking into that now, there's quite a bit of renaming in 1.75.0
2024-02-06 13:32:37 <cely> and i think a follow up to the Github pull request associated with main/rust/lfs64-rust.patch was merged into 1.75.0
2024-02-06 13:33:25 <cely> so optimistically rm'ing it, and let's see what the CI thinks of that later
2024-02-06 13:34:40 <omni> I'm getting distraced by other things meanwhile
2024-02-06 13:34:52 <omni> perhaps I should follow and review what you do instead
2024-02-06 13:36:14 <cely> Yes, once i get proof that the half patched Rust 1.73 can build a Rust 1.74 without the patch which can in turn build a Rust 1.75, i'll leave a link to the branch
2024-02-06 13:37:50 <omni> alice suggested to continue "completely without the patch, then 1.74"
2024-02-06 13:42:42 <cely> i'll have a look at the Gitlab comment
2024-02-06 14:05:02 <cely> i got Rust 1.74 to build with Rust 1.73 half unpatched
2024-02-06 14:06:39 <cely> omni: btw, i used the rust1730, rust1740 method you used in your previous MR
2024-02-06 14:09:35 <cely> Proof that 1.73 half unpatched builds 1.74 on x86_64: https://gitlab.alpinelinux.org/Celeste/aports/-/jobs/1267879
2024-02-06 14:10:00 <cely> and on armv7: https://gitlab.alpinelinux.org/Celeste/aports/-/jobs/1267893
2024-02-06 14:11:44 <omni> well, to say that I used the method would be an overstatement, I think I never succeeded
2024-02-06 14:12:30 <omni> hello, I'm from the future, rust 1.76.0 was "Released on: 8 February, 2024" https://releases.rs/docs/1.76.0/
2024-02-06 14:13:27 <cely> and now for the grand finale of this building that: https://gitlab.alpinelinux.org/Celeste/aports/-/jobs/1267943
2024-02-06 14:14:38 <omni> I saw an error: >>> ERROR: rust-aux*: libscudo.so: path not found
2024-02-06 14:14:42 <cely> This is the branch for your review: https://gitlab.alpinelinux.org/Celeste/aports/-/tree/rust-to-the-1.75
2024-02-06 14:16:22 <cely> You have a keen eye, but as scudo-malloc is listed explicitly in the APKBUILD of the proper main/rust/APKBUILD, i don't think that's to worry about
2024-02-06 14:16:52 <cely> Anyway, you'll have to undo all that 1740 stuff in the APKBUILD, and of course the arch= line
2024-02-06 14:17:46 <cely> Here i'm just testing if the half unpatched 1.73.0 from !60301 can successfully build 1.74.0 (no patch here) which in turn can build 1.75.0
2024-02-06 14:18:21 <cely> At least on x86_64
2024-02-06 14:18:23 <cely> hehe
2024-02-06 14:20:19 <cely> I think if 1.75.0 at the end of the chain is successful, i'd say we don't need to rebuild 1.73 completely without the patch, as 1.75 (if successful) would already be once removed from that
2024-02-06 14:20:55 <omni> ok, but should I go ahead and merge 60301 then?
2024-02-06 14:21:06 <cely> Of course!
2024-02-06 14:21:42 <cely> I was done testing that a few hours ago, if you don't see anything that looks surprising, it should be good to go
2024-02-06 14:21:47 <omni> sorry for stalling then =)
2024-02-06 14:22:09 <omni> I guess I also wanted it to succeed on arm*
2024-02-06 14:25:47 <cely> I guess the conclusion now is, if my CI job for 1.75.0 succeeds (hopefully i didn't make any silly mistakes while modifying the patches), we go straight to 1.74.0
2024-02-06 14:26:29 <cely> if it errors out with something that looks like 1.73.0 needs another rebuild to rid it of the patch, then we do that instead
2024-02-06 14:28:22 <cely> If you look at the 'main/rust: upgrade to 1.74.0' commit from my branch, you'll see there isn't too much modifications needed for the patch
2024-02-06 14:28:51 <cely> I thought it would be better to go straight to /bin/sh instead of going through /usr/bin/env, but you may ignore that if you think it's unnecessary
2024-02-06 14:29:43 <cely> The rest is just taking into consideration `target_os = "hurd"` in lfs64-rust.patch
2024-02-06 14:46:51 <cely> and it seems Rust 1.75.0 has panicked
2024-02-06 14:53:19 <cely> Hmm, the file isn't in 1.74, so probably reorganized from somewhere else
2024-02-06 15:07:37 <cely> Seems we've hit this issue: https://github.com/rust-lang/rust/issues/117885
2024-02-06 15:08:40 <cely> I've backported https://github.com/rust-lang/rust/pull/119582 and rebased my rust-to-the-1.75 branch
2024-02-06 15:13:09 <cely> Alright, one last try to push ahead to 1.75.0, if it fails again, then i guess we have more time, and can rebuild 1.73.0 yet again, haha
2024-02-06 15:15:16 <omni> also saw https://releases.rs/docs/1.74.1/
2024-02-06 15:16:01 <omni> haven't really looked at it but would that be something in between instead of 1.74.0?
2024-02-06 15:17:05 <cely> Hmm
2024-02-06 15:17:06 <cely> Might be workable
2024-02-06 15:17:40 <cely> So, i guess your MR could be for 1.74.1 instead
2024-02-06 15:18:49 <cely> We already know 1.74.0 builds on x86_64 and armv7, so if 1.74.1 also builds successfully, i'd say we can go from 1.73.0 to 1.74.1
2024-02-06 15:20:10 <cely> Hehe !60307 failed on the 2 architectures that haven't been uploaded yet
2024-02-06 15:22:14 <cely> Ah now x86 can be retried :)
2024-02-06 15:24:22 <cely> Anyway, if you go along with 1.74.0, i guess that will be alright too (we'll know roughly how to proceed once my 1.75 CI job finishes)
2024-02-06 15:30:07 <cely> I think Rust 1.75 is our destination, so it doesn't matter much whether we take the 1.74.0 route or the 1.74.1 route
2024-02-06 15:31:16 <cely> It seems we've been building 1.74.0 a lot, so if nothing new breaks, i think we should just go with that
2024-02-06 16:18:34 <cely> i wonder what errors i'll see if i try building 1.75 with 1.73
2024-02-06 16:19:26 <cely> Haha
2024-02-06 16:19:50 <cely> "Unexpected rustc version: 1.73.0, we should use 1.74.x/1.75.0 to build source with 1.75.0"
2024-02-06 16:20:26 <cely> So, it does a check to make sure you follow the rules
2024-02-06 16:22:21 <omni> I'm sure that can be patched :D
2024-02-06 16:28:36 <cely> Now i'll be trying to build 1.75.0 with your 1.74.1
2024-02-06 16:31:41 <cely> i'm using a new branch now: https://gitlab.alpinelinux.org/Celeste/aports/-/tree/rust-to-the-1.75-again
2024-02-06 16:31:51 <cely> rebased on your 1.74.1 branch
2024-02-06 16:32:27 <cely> so hopefully it is easier to extract the commit with the patch modifications (of which there are many)
2024-02-06 16:32:57 <cely> Lots of reorganizations, also lots of things upstreamed
2024-02-06 16:33:36 <cely> When you take a look at it, don't forget `bootstrap-vendor-remap.patch`, that fixes an issue for us
2024-02-06 16:34:24 <cely> as we pass `--set="rust.remap-debuginfo=true"` to ./configure
2024-02-06 16:34:56 <omni> in your -again branch you mean?
2024-02-06 16:35:34 <cely> Yes
2024-02-06 16:35:43 <omni> let's merge !60307 once riscv64 is done with 1.73.0-r1, right?
2024-02-06 16:36:00 <cely> It should be cleaner, and easier to extract the commit with the changes needed for the 1.75.0 upgrade
2024-02-06 16:36:03 <cely> Yes, sure
2024-02-06 16:36:23 <cely> Might not even need to wait for that, hehe
2024-02-06 16:38:07 <cely> Hopefully we get straight to 1.75.0, so it can be tested out in the few days before 1.76.0 is released
2024-02-06 16:39:04 <omni> yes
2024-02-06 16:39:33 <omni> but just getting to 1.74.x will enable us to upgrade a few aports and remove some patches for others, right?
2024-02-06 16:39:49 <cely> What patches are you thinking about?
2024-02-06 16:40:10 <cely> dua-cli had a patch, but that's been upstreamed
2024-02-06 16:40:25 <omni> I just thought there were several
2024-02-06 16:40:34 <omni> perhaps not
2024-02-06 16:40:47 <cely> Might be, but i can't think of anything off the top of my head
2024-02-06 16:40:57 <cely> and yes 1.74.x will enable quite a few aports
2024-02-06 16:41:06 <omni> me neither but I couldn't even think of dua-cli
2024-02-06 16:41:17 <cely> but i think 1.75.0 added some async stuff, so aports wanting those will still be awaiting 1.75 :)
2024-02-06 16:41:37 <omni> I'll afk for a bit and then riscv64 is probably done with 1.73.0-r1 and I'll merge the 1.74.1 upgrade
2024-02-06 16:41:48 <cely> Sure, sounds good
2024-02-06 16:41:55 <cely> i'll also go AFK soon
2024-02-06 16:42:05 <cely> but will probably wait to see the results of my 1.75 CI
2024-02-06 16:42:32 <cely> Thankfully LLVM 17 seems to have given Rust a speed boost
2024-02-06 16:42:41 <cely> and probably also the newer Rust versions :)
2024-02-06 17:02:06 <ikke> speed boosts are always appreciated
2024-02-06 17:03:03 <cely> :)
2024-02-06 17:15:31 <cely> https://gitlab.alpinelinux.org/Celeste/aports/-/jobs/1268106
2024-02-06 17:15:45 <cely> So, 1.75.0 built fine, but failed tests
2024-02-06 17:16:31 <cely> Searching for the error message brought me to: https://github.com/rust-lang/rust/issues/119571
2024-02-06 17:16:55 <cely> which is an open issue
2024-02-06 17:18:00 <cely> I guess someone who writes Rust will have to take a look at how tests are done, maybe it's time to do some modifications to the tests as well
2024-02-06 17:25:42 <cely> Anyway, omni, if you can find the time to do it after mergin 1.74.1, i think it would still be good to have an MR for 1.75.0
2024-02-06 17:27:00 <cely> https://gitlab.alpinelinux.org/Celeste/aports/-/commit/d4398272b from my rust-to-the-1.75-again branch should be enough to make 1.75 build (but tests will most likely fail)
2024-02-06 17:27:37 <cely> However, it's still good to let more people have a look at the changes, and see if there are any architectures where the tests don't error out
2024-02-06 17:28:13 <cely> They're disabled on 32-bit arm and riscv64 though
2024-02-06 17:33:11 <cely> I'll probably have another go at it tomorrow, but not sure how i would solve the test issue, maybe i can dream up something :)
2024-02-06 17:47:05 <omni> yeah, I'll open a 1.75.0 MR
2024-02-06 17:47:56 <omni> riscv64 is sure taking its time
2024-02-06 18:26:28 <omni> there, let's see..
2024-02-06 22:00:39 <omni> I think riscv64 was first to start building rust-1.74.1-r0 but armv7 was first to finish
2024-02-06 22:21:37 <omni> oh no...
2024-02-06 22:30:13 <omni> algitbot: retry master
2024-02-06 22:42:33 <omni> uh.. built fine with rust 1.73.0-r1
2024-02-06 23:24:29 <omni> so, looks like a bunch of MRs were rebased to see if they build with newer rust so now everything is super slow
2024-02-06 23:35:59 <ptrc> omni: if it was one that i rebased, feel free to cancel it
2024-02-06 23:38:42 <omni> I don't see any running that you rebased
2024-02-06 23:38:52 <omni> but I'll let them be
2024-02-06 23:41:48 <omni> one thing I'd like to see now is if arti will fail on other architectures too
2024-02-06 23:41:51 <omni> probably
2024-02-06 23:43:21 <omni> and x86* just started building rust-1.74.1-r0, the others are done
2024-02-06 23:44:37 <omni> "An error occurred while making the request." while trying to re-trigger the pipeline for ppc64le in 60315
2024-02-06 23:44:45 <omni> !60315
2024-02-06 23:45:40 <omni> there is something with the UI today...
2024-02-07 00:18:33 <omni> ok
2024-02-07 00:37:14 <celie> So, Arti doesn't build with new Rust?
2024-02-07 00:38:12 <celie> Anyway, regarding the Gitlab UI, i've also noticed something a bit off
2024-02-07 00:38:45 <omni> not sure if new rust is the issue with arti or something that is different with the package builders compared to the CI builders
2024-02-07 00:39:06 <omni> I think there was something similar once before with the tor aport
2024-02-07 00:40:11 <celie> I think the CI would still show as running on the MR page, but actually, it's already done
2024-02-07 00:40:32 <omni> but more importantly, rust 1.75.0 tests are failing for at least aarch64 and armhf
2024-02-07 00:40:46 <omni> riscv64 currently running and others I don't know
2024-02-07 00:44:19 <celie> Maybe we really need to consider having a testing/rust-nightly, at least for a few architectures, so we can find these upgrade issues before they hit stable
2024-02-07 00:44:29 <celie> Rust stable, i mean
2024-02-07 00:48:42 <omni> I just saw something...
2024-02-07 00:48:50 <cely> What is it?
2024-02-07 00:50:30 <omni> https://github.com/rust-lang/rust/pull/40113 mentioned in musl-fix-linux_musl_base.patch
2024-02-07 00:50:45 <omni> perhaps try without that patch?
2024-02-07 00:53:18 <cely> Hmm, i'm not so sure, is the CI still being slow?
2024-02-07 00:54:48 <omni> I'm not sure either
2024-02-07 00:55:26 <omni> oh, time for chromium upgrades :D
2024-02-07 00:57:25 <cely> Also, i just noticed https://github.com/msrd0/docker-abuild-arm/tree/main/rust
2024-02-07 00:57:50 <cely> That's on 1.75.0
2024-02-07 00:58:12 <cely> Maybe you could see if there's anything different in the patches there
2024-02-07 00:58:49 <omni> and I saw that voidlinux is at rust 1.75.0 too
2024-02-07 00:59:04 <cely> Hehe, it contains !check in options
2024-02-07 00:59:09 <cely> so probably won't help us out there
2024-02-07 00:59:20 <omni> https://github.com/void-linux/void-packages/tree/master/srcpkgs/rust
2024-02-07 00:59:36 <cely> but at least we can compare the patches
2024-02-07 00:59:40 <omni> yeah
2024-02-07 01:02:13 <omni> I think I need a break
2024-02-07 01:02:16 <cely> Even OpenBSD is at Rust 1.75.0 ;)
2024-02-07 01:02:25 <omni> :D
2024-02-07 01:03:01 <omni> there, just x86 left to be done with 1.74.1-r0
2024-02-07 01:03:08 <cely> :)
2024-02-07 01:06:42 <omni> \o/
2024-02-07 01:09:35 <cely> I'm just about to have a go at the test issue
2024-02-07 01:09:47 <cely> but don't know if the CI is still overloaded
2024-02-07 01:10:55 <omni> well... !60328 & !60333 :D
2024-02-07 01:14:36 <omni> cely: I say try, just use patience
2024-02-07 01:15:19 <omni> algitbot: retry master
2024-02-07 01:17:42 <cely> Oh, i don't want to be competing with Chromeium
2024-02-07 01:22:11 <cely> I don't think we should allow Rust 1.75.0 to be blocked again
2024-02-07 01:22:32 <omni> what do you mean?
2024-02-07 01:22:49 <cely> So, i'd say probably give it max a week for someone to solve the test issue, or we just disable tests if things look fine
2024-02-07 01:23:14 <omni> aha
2024-02-07 01:23:52 <cely> as they aren't even upstream's tests anyway
2024-02-07 01:25:05 <omni> I haven't really dug into the tests
2024-02-07 01:32:01 <cely> Hmm, i see the APKBUILD has something for rust-analyzer
2024-02-07 01:32:15 <cely> i mean, it enables something for the archs rust-analyzer is enabled for
2024-02-07 01:36:44 <cely> Hmm, i wonder if we need to run `_clear_vendor_checksums` on libc-0.2.148 and libc-0.2.149
2024-02-07 01:38:51 <cely> However, i think logically, vendor checksums would only need to be cleared if we were patching something
2024-02-07 01:39:20 <cely> and in Rust 1.75.0 we don't patch anything with the .patch.noauto files
2024-02-07 01:39:45 <cely> So, maybe the whole `prepare()` can be removed
2024-02-07 01:42:21 <cely> algitbot: retry master
2024-02-07 01:44:42 <cely> Hmm, libei seems to build fine now
2024-02-07 01:45:01 <cely> or rather, test fine
2024-02-07 01:53:39 <omni> cely: well, I did that, didn't I?
2024-02-07 01:54:04 <omni> perhaps you just continued from your fork, I did some additional changes
2024-02-07 01:56:26 <cely> Oh, sorry, i probably should go see what changes you made
2024-02-07 01:57:16 <omni> yes, maybe I did something on my own that made everything fail =)
2024-02-07 01:58:10 <cely> Nah, the test failure was already there when i tried it in my fork
2024-02-07 01:59:35 <omni> ok
2024-02-07 01:59:56 <omni> something something "rpath" and we patch some things "rpath"
2024-02-07 02:01:16 <omni>  // XXX: hacky hacky
2024-02-07 02:01:38 <cely> 
ACTION waits for the rest of the paste

2024-02-07 02:02:53 <omni> nah, that's it
2024-02-07 02:03:05 <omni> main/rust/need-rpath.patch
2024-02-07 02:03:21 <omni> the important part at least
2024-02-07 02:03:57 <omni> comments are the most important part of code
2024-02-07 02:04:13 <omni> and programming is about removing code, right?
2024-02-07 02:10:49 <cely> Not really sure i'm getting your point
2024-02-07 02:11:21 <omni> no, I'm just being silly
2024-02-07 02:11:46 <omni> but I'm looking at main/rust/need-rpath.patch
2024-02-07 02:11:57 <cely> That's good, thanks :)
2024-02-07 02:12:17 <omni> because it is patching compiler/rustc_codegen_ssa/src/back/link.rs
2024-02-07 02:12:56 <omni> and the test was failing somewhere around there
2024-02-07 02:13:07 <omni> I may or may not be onto something
2024-02-07 02:14:51 <cely> However, msrd0/docker-abuild-arm still applies that
2024-02-07 02:20:34 <omni> mm...
2024-02-07 02:21:02 <omni> yeah, I should probably have a look at theirs and the void patches
2024-02-07 02:24:26 <cely> Probably want to see if there's anything they've stopped applying
2024-02-07 02:27:01 <cely> Hmm, it really is bad
2024-02-07 02:27:04 <cely> Rust can't compile anything
2024-02-07 02:29:07 <omni> I think our test is failing at https://github.com/rust-lang/rust/commit/5aeb6a326f2fa941061b60c9286665847fe0401e#diff-4622a614fea8371c5c7b44c71f9c4959f377fa0e08dce6fd9a9cfde7dd4d7477R88
2024-02-07 02:29:44 <omni> called `Result::unwrap()` on an `Err` value: Error { kind: InvalidInput, message: "cannot make an empty path absolute" }
2024-02-07 02:29:58 <omni> is the line from our test
2024-02-07 02:30:19 <omni> uhm meant to paste this line:
2024-02-07 02:30:20 <omni> thread 'rustc' panicked at compiler/rustc_codegen_ssa/src/back/rpath.rs:88:43:
2024-02-07 02:30:57 <omni> and the above diff is what is different for that file between 1.74.1 and 1.75.0
2024-02-07 02:37:59 <cely> i was just looking at that too :)
2024-02-07 02:40:14 <cely> Aha!
2024-02-07 02:40:32 <cely> i just got `rustc` to compile something
2024-02-07 02:40:43 <cely> it turns out you not only need -o
2024-02-07 02:41:40 <cely> the out_filename (i guess that's what `config.out_filename` in the code is referring to) must have a directory (either absolute path, or ./)
2024-02-07 02:46:24 <cely> So, if i modify all the `_rustc` calls in `check-rustc` to include `-o ./<filename>` they pass
2024-02-07 02:46:50 <cely> The ones with +crt-static don't need and still pass that though
2024-02-07 02:46:57 <cely> don't need that*
2024-02-07 02:48:26 <omni> hmm.. ok
2024-02-07 02:49:00 <omni> I just saw in our APKBUILD:
2024-02-07 02:49:02 <omni> # This is related to change-rpath-to-rustlib.patch.
2024-02-07 02:49:17 <omni> but don't see no change-rpath-to-rustlib.patch
2024-02-07 02:49:36 <omni> I think it is unrelated to our current issue, but still
2024-02-07 02:50:04 <omni> there is some cleanup that we might as well do now
2024-02-07 02:50:20 <cely> After seeing that need-rpath.patch is equivalent to always having `-Crpath` set
2024-02-07 02:50:45 <cely> and looking at the commit you mentioned
2024-02-07 02:51:01 <cely> i am more certain this issue is related to https://github.com/rust-lang/rust/issues/119571
2024-02-07 02:51:22 <cely> It is still an open issue, and i don't see any pull requests linked to it
2024-02-07 02:55:23 <cely> i wonder if we should just revert that commit
2024-02-07 02:59:05 <omni> the whole https://github.com/rust-lang/rust/pull/116487 ?
2024-02-07 02:59:37 <omni> or just https://github.com/rust-lang/rust/pull/116487/commits/5aeb6a326f2fa941061b60c9286665847fe0401e ?
2024-02-07 03:04:12 <cely> Probably try with just the commit first
2024-02-07 03:04:31 <cely> i wonder if cargo ever calls rustc without a proper -o
2024-02-07 03:05:14 <cely> if cargo always provides a proper -o, then very likely most people are never going to encounter this issue
2024-02-07 03:06:07 <cely> We only have this because `check-rustc` calls rustc directly
2024-02-07 03:07:05 <cely> and looking at need-rpath.patch now
2024-02-07 03:07:20 <cely> if we set RUSTC_BOOTSTRAP when running `check-rustc` it works too
2024-02-07 03:09:22 <omni> I was almost about to push with that commit reverted
2024-02-07 03:11:18 <omni> well, I will
2024-02-07 03:11:59 <omni> this is a potentially breaking change for some rust users, isn't it?
2024-02-07 03:13:52 <cely> You mean reverting the commit or not reverting it?
2024-02-07 03:14:25 <cely> If you mean not reverting it, as i was saying, i think most users use rust through cargo
2024-02-07 03:14:34 <cely> and don't call rustc directly
2024-02-07 03:16:22 <omni> I mean not reverting "rustc_codegen_ssa: use try_canonicalize in rpath"
2024-02-07 03:16:28 <omni> would be breaking for some
2024-02-07 03:16:53 <omni> by upgrading to 1.75.0
2024-02-07 03:17:49 <cely> i've just tried it
2024-02-07 03:17:53 <cely> cargo compiles things fine
2024-02-07 03:18:01 <cely> so, only users that call rustc directly would be affected
2024-02-07 03:18:13 <cely> (like the `check-rustc` script we run in `check()`)
2024-02-07 03:18:32 <cely> So, i'm not sure about breaking
2024-02-07 03:19:31 <cely> So, either we revert that commit, or hunt down the `Path::from("empty")` mentioned in https://github.com/rust-lang/rust/issues/119571 and try to patch that instead, or just set RUSTC_BOOTSTRAP=1 while running `check-rustc`
2024-02-07 03:19:33 <omni> some users may be calling rustc directly
2024-02-07 03:19:58 <cely> Probably
2024-02-07 03:20:06 <cely> but my impression is everyone uses cargo now ;p
2024-02-07 03:20:44 <cely> and you'll need to call rustc without a proper -o (so it makes an executable with the filename of the source file minus the extension)
2024-02-07 03:21:24 <cely> Anyway, either reverting it or setting RUSTC_BOOTSTRAP is fine with me
2024-02-07 03:21:33 <cely> So, i will go with what you decide
2024-02-07 03:21:59 <cely> and if the decision affects some other thing in an unexpected way, other users will let us know :)
2024-02-07 03:23:36 <cely> Hmm, we probably have to take into consideration need-rpath.patch, i mean this isn't entirely due to upstream's change
2024-02-07 03:23:53 <cely> it's upstream's change + our patch to always enable `-Crpath`
2024-02-07 03:24:53 <cely> So, maybe reverting that commit is a good idea
2024-02-07 03:25:26 <cely> at least, until someone reviews whether need-rpath.patch is still needed
2024-02-07 03:26:45 <cely> and there's a Github issue you can reference in your patch reverting the commit, so at least we have something to watch to know when to unrevert it
2024-02-07 03:26:45 <omni> I mean, 'rustc hello_world.rs' would be pretty common for people to run when starting out with rust
2024-02-07 03:27:22 <omni> I'll add coments and also rename my revert-patch
2024-02-07 03:27:51 <cely> https://www.rust-lang.org/learn/get-started
2024-02-07 03:28:17 <cely> "Let's write a small application with our new Rust development environment. To start, we'll use Cargo to make a new project for us." :)
2024-02-07 03:29:18 <omni> hah
2024-02-07 03:29:37 <omni> well, I read src/doc/rustc/src/what-is-rustc.md
2024-02-07 03:32:39 <cely> ah, i looked at the output of `cargo build --verbose` and cargo calls rustc with --out-dir set
2024-02-07 03:32:44 <cely> so that also fixes the issue
2024-02-07 03:33:05 <omni> https://doc.rust-lang.org/rustc/index.html
2024-02-07 03:33:36 <cely> Anyway, i think we're on the same page now, which is, revert the commit, and watch the Github issue
2024-02-07 03:34:21 <omni> yeah, I already pushed with reverting the commit and it's building
2024-02-07 03:34:43 <omni> but I'll rename my patch and add some comments
2024-02-07 03:35:04 <cely> Let's see if the tests pass first
2024-02-07 03:59:59 <omni> cely: x86 succeeded
2024-02-07 04:00:59 <cely> That's great :)
2024-02-07 04:01:25 <cely> x86_64 also now
2024-02-07 04:08:50 <omni> that's enough for me, I'll push the patch name change commit with comments
2024-02-07 04:11:37 <omni> so now I'll let them all run, and I've also triggered riscv64
2024-02-07 04:14:00 <omni> cely: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/60315/diffs#0de429d99058768d45ad905892a469bf75627150
2024-02-07 04:14:54 <omni> gtg, c u l8r
2024-02-07 04:15:00 <cely> Bye
2024-02-07 04:15:19 <cely> Diff looks good
2024-02-07 04:44:28 <cely> Seems like the latest rust-beta from (2024-02-04) is already 1.77.0, and the last beta of 1.76.0 is from 2024-01-28
2024-02-07 05:12:55 <cely> Oops, armv7 failed tests
2024-02-07 05:13:53 <cely> i think that means the "+crt-static still broken" comment is still valid
2024-02-07 05:15:08 <cely> Let's see if the tests similarly fails for armhf and riscv64
2024-02-07 05:15:17 <cely> Ok, it just failed for armhf
2024-02-07 05:30:00 <cely> Btw, since riscv64 doesn't run tests on the builder anyway, if nothing else (besides the tests) errors out this time, you probably don't have to run the riscv64 CI and wait for it to finish again when you add the !check back due to broken +crt-static
2024-02-07 05:53:19 <cely> Based on beta9 from 2024-01-28, i think 1.76.0 should be a straight-forward upgrade
2024-02-07 05:57:14 <cely> No changes in patches, unless you want to align them again
2024-02-07 05:59:10 <cely> For 1.77.0 though (for now), bootstrap-vendor-remap.patch has been merged, and there's a rename affecting need-ssp_nonshared.patch
2024-02-07 05:59:36 <cely> but probably too early to plan for that now, considering 1.77.0 can't even be built yet, hehe
2024-02-07 10:39:54 <omni> cely: that the same tests fail on arm* and riscv64 is a clue, I think, and I'd like to try to do something about that
2024-02-07 12:27:50 <cely> Will you be using the solution from !60344?
2024-02-07 12:32:26 <omni> cely: no_empty_output_rpath.patch?
2024-02-07 12:32:33 <cely> Yes
2024-02-07 12:32:55 <omni> instead of reverting the other thing you mean
2024-02-07 12:33:12 <cely> Yes
2024-02-07 12:35:06 <omni> let's do that, and also disable tests for arm* and riscv64 again
2024-02-07 12:35:59 <omni> and, to jinx it, then I think we're ready for 1.75.0!
2024-02-07 12:43:08 <cely> i would rather it be patched closer to the source though
2024-02-07 12:43:46 <cely> As in, the actual place that calls it with an empty path, rather than checking for the empty path and returning something else if it finds it
2024-02-07 12:53:07 <omni> so the revert patch may be a better option after all?
2024-02-07 12:53:52 <omni> I don't feel like I'm in as much of a hurry with 1.75.0 and so don't mind ironing things out
2024-02-07 12:54:16 <omni> being stuck at pre-1.74 was more of a blocker
2024-02-07 12:58:10 <cely> Lots of things still depend upon 1.75.0
2024-02-07 12:58:30 <cely> which is why you got another MR upgrading it to that
2024-02-07 12:58:44 <omni> yes yes..
2024-02-07 12:58:49 <cely> From my own draft MR's, i can think of: hurl, lemmy, pict-rs
2024-02-07 12:59:28 <cely> Maybe you can ask Kladky if he knows where the output_directory could be coming from
2024-02-07 12:59:37 <cely> or rather, out_directory
2024-02-07 12:59:51 <cely> i keep circling back to compiler/rustc_session/src/config.rs
2024-02-07 13:00:07 <omni> or could you? =)
2024-02-07 13:00:13 <omni> in !60315 then
2024-02-07 13:01:01 <omni> and also your comment about "rather it be patched closer to the source" so that it is not lost
2024-02-07 13:06:28 <cely> Maybe i will ask another question instead
2024-02-07 13:08:21 <omni> sure
2024-02-07 13:08:22 <cely> If no plan to submit it upstream, then maybe we should stick with the original revert
2024-02-07 13:10:40 <cely> At least until the revert stops applying, or there is some activity on the Github issue trying to get it fixed
2024-02-07 13:18:51 <omni> so my current plan is to run the CI pipelines with their patch, because this cat is curious, then revert to the revert patch and then get it in
2024-02-07 13:19:38 <cely> omni cat is curious?
2024-02-07 13:19:39 <cely> :)
2024-02-07 13:20:05 <omni> 😼
2024-02-07 13:20:38 <omni> but I see now that their pipelines ran...
2024-02-07 13:21:04 <cely> The results from CI here replicate that from !60344
2024-02-07 13:21:09 <cely> hehe
2024-02-07 13:21:51 <cely> should replicate*
2024-02-07 13:22:32 <omni> they also --set="rust.remap-debuginfo=false"
2024-02-07 13:22:40 <cely> ...
2024-02-07 13:23:18 <cely> That's what bootstrap-vendor-remap.patch is for
2024-02-07 13:23:40 <omni> ah
2024-02-07 13:23:57 <cely> So, i guess Kladky wasn't basing the MR upon our work, which means it could be just a personal experiment, not actually intended to be merged
2024-02-07 13:26:44 <omni> now x86_64 is done
2024-02-07 13:27:27 <cely> :)
2024-02-07 13:28:36 <cely> i guess you should just merge what you had previously then (with the revert patch), so there is some time to prepare for 1.76.0
2024-02-07 13:29:12 <cely> i think for my own MR's still in draft, i would want to wait for 1.76.0 before undrafting them
2024-02-07 13:29:35 <cely> since 1.76.0 looked like a straight-forward upgrade when i tried it out for x86_64
2024-02-07 13:30:13 <cely> and undrafting the MR's now could mean it runs on the CI with one version of Rust, and then another when it is actually merged
2024-02-07 13:31:39 <omni> pushed that
2024-02-07 13:33:33 <omni> cely: ok, last chance before I merge what is currently in !60315
2024-02-07 13:34:13 <cely> 
ACTION looks

2024-02-07 13:36:28 <cely> Looks good :)
2024-02-07 13:37:19 <omni> ok, let's go!
2024-02-07 13:38:00 <cely> Thanks
2024-02-07 13:38:22 <cely> ..
2024-02-07 13:38:32 <omni> wat
2024-02-07 13:38:33 <omni> stap!
2024-02-07 13:38:46 <cely> Connection timed out :)
2024-02-07 13:39:02 <cely> algitbot: retry master
2024-02-07 13:39:04 <omni> *phew*
2024-02-07 13:39:42 <omni> well.. let's give it a couple of minutes
2024-02-07 13:39:44 <cely> i wonder if we were hitting static.rust-lang.org too much with our constant CI runs and upgrades
2024-02-07 13:40:24 <omni> maybe
2024-02-07 13:41:03 <cely> i wonder if we broke a record in the number of downloads
2024-02-07 13:41:09 <omni> but isn't also the ppc64le located elsewhere?
2024-02-07 13:41:11 <omni> ikke: ?
2024-02-07 13:42:09 <ikke> It's hosted by OSU
2024-02-07 13:43:44 <cely> Hmm, the builders still seem to be using curl for abuild-fetch
2024-02-07 13:43:59 <cely> (the CI uses wget now)
2024-02-07 13:44:39 <cely> but probably not connected
2024-02-07 13:45:00 <cely> and looking at build.a.o, ppc64le seems to have retried rust
2024-02-07 13:46:52 <omni> 
ACTION suspects someone doing things behind the scenes...

2024-02-07 13:47:06 <cely> So, what are our plans for 1.76 tomorrow?
2024-02-07 13:47:17 <omni> as, in a way, we are when talking here rather than in #alpine-devel
2024-02-07 13:47:37 <cely> hehe
2024-02-07 13:47:38 <omni> yeah, I was thinking about 1.76 too...
2024-02-07 13:53:52 <omni> maybe one could fetch a commit tarball that would be close to what 1.76.0 will be?
2024-02-07 13:56:15 <cely> https://static.rust-lang.org/dist/2024-01-28/rustc-beta-src.tar.xz
2024-02-07 13:56:25 <cely> 1.76.0-beta9
2024-02-07 13:57:06 <cely> The last beta of 1.76.0, it seems, the current beta from a few days ago is of 1.77.0
2024-02-07 13:57:37 <omni> thanks!
2024-02-07 13:57:47 <cely> You're welcome
2024-02-07 13:57:53 <cely> but not buildable until 1.75.0 hits the builders
2024-02-07 13:58:09 <cely> So, probably what you can do for now is align the patches :)
2024-02-07 13:58:20 <omni> yeah, and whatnot...
2024-02-07 14:02:39 <cely> Hmm, i just noticed, Kladky's modifications (remap-debuginfo=false, or something else) seems to have removed scudo-malloc as dependency
2024-02-07 14:04:05 <cely> Oh no
2024-02-07 14:04:07 <cely> hehe
2024-02-07 14:04:10 <cely> My mistake
2024-02-07 14:04:52 <cely> scudo-malloc is not patchelf'd for 32-bit ARM
2024-02-07 14:06:02 <cely> Comment says link scudo-malloc "on architectures where it works well"
2024-02-07 14:06:11 <cely> i guess that means it causes some problems for the ARM's
2024-02-07 14:06:57 <cely> it also mentions "higher memory use", so maybe to avoid hitting the 4gb limit for 32-bit or something
2024-02-07 14:10:03 <omni> mm...
2024-02-07 14:11:45 <omni> btw, aligning patches.. I have this idea that it may be useful for tracking when things have changed and where, but it's mostly gut feeling
2024-02-07 14:14:47 <omni> other than that, it's just cosmetics
2024-02-07 14:14:56 <cely> Oh, another thing
2024-02-07 14:15:06 <cely> i think the source files are installed into the .apk
2024-02-07 14:15:23 <cely> and i think i saw some .orig's ;)
2024-02-07 14:16:39 <cely> Just left a comment on !58129
2024-02-07 14:18:03 <omni> 👍
2024-02-07 14:18:10 <omni> I've seen .orig's too
2024-02-07 14:20:58 <cely> However, the signal mentioned in the Github issue is 11 SIGSEGV, while the one from CI is 6 SIGABRT
2024-02-07 14:24:19 <cely> 1.75.0 is aarch64 :)
2024-02-07 14:24:20 <cely> s/is/in/
2024-02-07 14:26:04 <omni> !60356
2024-02-07 14:27:40 <cely> hehe, you are quick, thanks
2024-02-07 14:30:17 <omni> well, motivated =)
2024-02-07 14:33:34 <omni> I'd also like to see if there are other improvements that could be made and get in with the 1.76.0 release
2024-02-07 14:35:59 <omni> it would also be fun to upgrade to 1.76.0 as soon as possible after it is released
2024-02-07 14:37:18 <cely> i wonder if we can use default_*shcomp for the cargo shell completions, and just override `install_if`
2024-02-07 14:39:07 <cely> Oh but, the default pkgdesc will get $pkgname wrong
2024-02-07 14:39:12 <cely> so probably not worth it
2024-02-07 14:41:38 <cely> Maybe all the calls to tar & could go into a for loop
2024-02-07 14:44:10 <cely> Oh now there is also an MR for sbcl
2024-02-07 14:58:02 <cely> Hehe, i've just found that the latest version of one of the aports i maintain (tootik) now requires Go 1.22
2024-02-07 15:16:30 <cely> Rust 1.76.0-beta9 has succeeded on aarch64
2024-02-07 15:16:54 <cely> and most of the architectures have 1.75.0 now, so probably time to retry the pipeline for those
2024-02-07 15:33:16 <omni> yeah, all but riscv64 and s390x
2024-02-07 15:38:53 <andypost[m]> celeste: quick and dirty attempt for go 1.22 !60365
2024-02-07 15:39:18 <celie> Yes, i saw that :)
2024-02-07 15:39:39 <celie> So the CI is now working on both Rust 1.76.0 (beta) and Go 1.22
2024-02-07 15:40:23 <celie> and thanks
2024-02-07 15:49:27 <andypost[m]> go 1.22 failed 32-bit arm but I requeued
2024-02-07 15:50:28 <celie> No hurry for Go 1.22, my aport upgrade can wait
2024-02-07 15:51:06 <omni> haha, rust 1.74.1 got flagged as out-of-date today
2024-02-07 15:51:59 <omni> before I think 1.73.0 was "ok"
2024-02-07 15:52:10 <omni> saw that when we went past 1.73.0
2024-02-07 15:52:18 <celie> On pkgs.a.o?
2024-02-07 15:52:35 <celie> Was it by the release-monitoring bot?
2024-02-07 15:52:49 <omni> can't tell
2024-02-07 15:53:00 <omni> but release-monitoring should have flagged earlier, no?
2024-02-07 15:53:23 <celie> Yeah, it's no longer on pkgs.a.o now
2024-02-07 15:53:24 <omni> I can only see here https://pkgs.alpinelinux.org/packages?name=rust&branch=edge&repo=&arch=&maintainer=
2024-02-07 15:54:02 <celie> but i've noticed, that even a pkgrel bump will cause release-monitoring to re-flag a package if its pkgver is not te latst
2024-02-07 15:54:15 <celie> the latest*
2024-02-07 15:56:19 <celie> Unless it was one of our users who flagged it, wanting 1.75.0 to build something :)
2024-02-07 15:59:21 <celie> and it seems removing `--target="$CTARGET"` fixes !58174 (armv7 CI passed)
2024-02-07 16:00:00 <celie> which probably means arbitrary is wrongly classified as not needed for the $CTARGET
2024-02-07 16:00:06 <celie> arbitrary, the crate, that is
2024-02-07 16:17:11 <omni> arbitrarily
2024-02-07 17:13:50 <omni> I just hope riscv64 is done building rust 1.75.0 before 1.76.0 comes out :D
2024-02-07 17:20:28 <ikke> oops. commit message
2024-02-07 17:25:53 <omni> haha
2024-02-07 17:27:25 <omni> ikke: was it someone who had changed the title of the MR but not the commit message?
2024-02-07 17:27:58 <ikke> nope, I wasn't paying enough attention apparently
2024-02-07 17:28:09 <ikke> !60349
2024-02-07 17:28:21 <ikke> It's not too bad
2024-02-07 17:28:43 <ikke> well, the MR title was different, yes
2024-02-07 17:29:45 <omni> I've merged worse
2024-02-07 17:29:51 <omni> probably you too :D
2024-02-07 17:29:55 <ikke> yup
2024-02-07 17:30:20 <omni> I think it's good to do mistakes like that from time to time, to shame yourself into paying more attention
2024-02-07 17:30:22 <omni> :D
2024-02-07 17:30:27 <ikke> haha, yes
2024-02-07 18:32:34 <omni> huh?
2024-02-07 18:32:40 <omni> algitbot: retry master
2024-02-07 19:44:09 <ikke> out of memory allocating 135266296 bytes after a total of 65536 bytes
2024-02-07 19:44:11 <ikke> humm
2024-02-07 20:33:49 <omni> the kernel doesn't usually fail to build on just x86 does it?
2024-02-07 20:34:42 <ikke> No, it doesn't
2024-02-07 20:38:38 <omni> ncopa: 
2024-02-07 21:46:43 <omni> soon riscv64 will start building rust 1.75.0!
2024-02-07 21:48:09 <omni> there
2024-02-07 23:10:22 <omni> let's see if we have better luck this time
2024-02-07 23:21:00 <omni> *sigh*
2024-02-07 23:37:36 <ptrc> omni: i assume you tried the TEST_TEMP_RETAIN thingy it mentions in the log?
2024-02-07 23:37:49 <ptrc> not that it would change much, i think
2024-02-07 23:38:25 <omni> my current plan is to disable the offending test
2024-02-07 23:38:34 <omni> !60379
2024-02-07 23:39:14 <omni> but seems like space ran out on the x86_64 CI builder
2024-02-07 23:39:39 <ptrc> but also, that test is immensely cursed
2024-02-07 23:41:18 <omni> https://gitlab.torproject.org/tpo/core/arti/-/issues/1264#note_2993649
2024-02-07 23:44:56 <ptrc> remind me, it succeeds locally and on the CI, but fails on the builders?
2024-02-07 23:46:02 <omni> yes
2024-02-07 23:46:29 <ptrc> it might very well be because builders ignore USR2, but.. the exit code 101 doesn't really make sense
2024-02-07 23:48:30 <ptrc> ah, no, it does
2024-02-07 23:49:30 <omni> makes sense?
2024-02-07 23:50:33 <ptrc> if you look up "rust exit code 101", that's ( for some random reason ) globally understood as a panic
2024-02-07 23:53:22 <omni> 🮲panic🮳🮲101🮳
2024-02-07 23:53:26 <ptrc> wha-
2024-02-07 23:53:41 <ptrc> is it just me or is that some garbled unicode
2024-02-07 23:54:04 <ptrc> but also, hm, on x86_64 the dbg! macro from line 600 does run properly
2024-02-07 23:55:04 <omni> U+1FBB2 & U+1FBB3
2024-02-07 23:55:21 <omni> 🮲🮳
2024-02-07 23:55:44 <omni> my terminal doesn't print it too well...
2024-02-07 23:56:06 <omni> but I like broken unicode too
2024-02-07 23:58:41 <omni> ptrc: huh?
2024-02-08 00:00:46 <ptrc> omni: what i mean is that it's probably that panic from the last line of the test, but it's really odd that it doesn't print anything
2024-02-08 00:12:17 <omni> ptrc: yeah, idk
2024-02-08 01:20:08 <omni> maybe someone is using the gitlab CI to mine shitcoins
2024-02-08 01:21:34 <cely> Is it really slow again?
2024-02-08 01:30:20 <cely> https://releases.rs/ has been updated to list 1.76.0 as Rust stable
2024-02-08 01:31:37 <cely> i wonder if it isn't just an automated thing though, that happens after midnight UTC
2024-02-08 01:34:16 <cely> Looking at the timestamps on https://static.rust-lang.org/dist/channel-rust-1.7x.y.toml the past 3 releases were done after noon UTC
2024-02-08 01:35:02 <omni> it's not here https://static.rust-lang.org/dist/rustc-1.76.0-src.tar.xz
2024-02-08 01:35:22 <omni> nor here https://github.com/rust-lang/rust/releases
2024-02-08 01:35:31 <omni> yet
2024-02-08 01:36:57 <omni> maybe it's not crypto pyramid scheme mining but just browser engines
2024-02-08 01:47:21 <ptrc> speaking of which, i forgot to do the firefox update; i'll wait until the CI is less busy though :p
2024-02-08 01:50:54 <omni> oh-no!
2024-02-08 01:51:00 <cely> It's in main!!
2024-02-08 01:51:01 <omni> but it was done with rust 1.75.0
2024-02-08 01:51:08 <cely> but has it been uploaded?
2024-02-08 01:51:21 <omni> I don't think it has if something else is blocking
2024-02-08 01:51:41 <cely> algitbot: retry master
2024-02-08 01:52:20 <cely> Ugh, vapigen terminated
2024-02-08 01:52:42 <cely> i've seen this with NetworkManager (or was it ModemManager) on 32-bit
2024-02-08 01:53:40 <cely> algitbot: retry master
2024-02-08 01:54:23 <ptrc> signal 11, isn't that a segfault?
2024-02-08 01:55:10 <cely> One more time
2024-02-08 01:55:11 <cely> algitbot: retry master
2024-02-08 01:56:19 <cely> i wonder if i mentioned anywhere the error i got from NetworkManager
2024-02-08 01:56:43 <cely> Yeap, signal 11
2024-02-08 01:56:54 <cely> Logs for this channel for November last year
2024-02-08 01:57:00 <cely> algitbot: retry master
2024-02-08 01:57:13 <ptrc> i can reproduce the segfault locally
2024-02-08 01:57:17 <ptrc> let me try and get a stacktrace
2024-02-08 01:57:50 <cely> but i don't think anyone did anything to make NetworkManager build
2024-02-08 01:58:04 <cely> it just sort of succeeded after many retries
2024-02-08 01:58:30 <cely> Oh wait, s/November/October/
2024-02-08 01:58:46 <cely> algitbot: retry master
2024-02-08 02:00:12 <ptrc> ah
2024-02-08 02:00:14 <ptrc> i segfaulted gdb
2024-02-08 02:00:18 <ptrc> trying to open the coredump
2024-02-08 02:00:31 <ptrc> that's not good
2024-02-08 02:00:48 <cely> algitbot: retry master
2024-02-08 02:00:55 <cely> What does that usually mean?
2024-02-08 02:02:00 <ptrc> i'm worried that something might be more broken than we think
2024-02-08 02:02:10 <cely> In riscv64?
2024-02-08 02:02:24 <cely> or other archs as well?
2024-02-08 02:02:40 <ptrc> rv64
2024-02-08 02:02:45 <ptrc> haven't seen a gdb segfault in ages
2024-02-08 02:02:52 <ptrc> and lldb doesn't build for rv64
2024-02-08 02:02:55 <cely> Ok
2024-02-08 02:03:06 <cely> Maybe you could try building libsecret 0.21.2 on riscv64
2024-02-08 02:03:22 <cely> That succeeded on the builder
2024-02-08 02:03:32 <cely> 2 months ago
2024-02-08 02:03:42 <ptrc> sure, lemme try
2024-02-08 02:04:00 <cely> Thanks :)
2024-02-08 02:04:09 <cely> algitbot: retry master
2024-02-08 02:04:40 <ptrc> same thing
2024-02-08 02:04:58 <ptrc> i wonder if i can copy the segfault to x86_64 and try viewing the stacktrace there somehow
2024-02-08 02:06:35 <cely> vala 0.56.14 was merged the same day as libsecret 0.21.2 but riscv64 used that vala to build libsecret
2024-02-08 02:06:51 <cely> and we haven't had a vala upgrade since then
2024-02-08 02:07:03 <ptrc> perhaps it's not related to vala after all
2024-02-08 02:07:14 <cely> Ok
2024-02-08 02:08:08 <ptrc> okay, i get the same segfault in gdb when running gdb-multiarch on my pc
2024-02-08 02:08:11 <ptrc> sigh
2024-02-08 02:10:21 <ptrc> ah!
2024-02-08 02:10:26 <ptrc> it's not vapigen nor anything
2024-02-08 02:10:30 <ptrc> it's qemu-riscv64 that's segfaulting
2024-02-08 02:11:09 <cely> That can't be good
2024-02-08 02:11:09 <ptrc> we still don't have native riscv64 builders ( soon? ), so we use userspace emulation
2024-02-08 02:13:19 <cely> Yes, you've mentioned that before :)
2024-02-08 02:17:40 <cely> So, what can we do here? If libsecret is temporarily disabled for riscv64, would it be deleted from the index and make all aports that depend upon it uninstallable?
2024-02-08 02:20:23 <ptrc> yeah, it would
2024-02-08 02:22:10 <cely> While looking through Rust history, i saw something psykose did: https://git.alpinelinux.org/aports/commit/community/rust?id=274194fd279
2024-02-08 02:22:32 <cely> Would something that work?
2024-02-08 02:22:40 <ptrc> oh, we did that because of some dumb issue before
2024-02-08 02:23:06 <ptrc> we.. could do that again, i guess?
2024-02-08 02:23:17 <cely> i guess it would, because Rust can't be removed from the index, otherwise it'd have to be re-bootstrapped
2024-02-08 02:28:02 <omni> heh..
2024-02-08 02:28:25 <ptrc> >>> qemu-dbg*: Running split function dbg...
2024-02-08 02:28:25 <ptrc> objcopy: Unable to recognise the format of the input file `/home/patrycja/aports/community/qemu/pkg/qemu/usr/share/qemu/s390-netboot.img'
2024-02-08 02:28:25 <ptrc> >>> ERROR: qemu-dbg*: dbg failed
2024-02-08 02:28:28 <ptrc> welp.
2024-02-08 02:28:41 <ptrc> here goes 20 minutes of building
2024-02-08 02:36:34 <ptrc> or maybe it's not qemu?
2024-02-08 02:36:36 <ptrc> i'm so confused
2024-02-08 02:36:48 <ptrc> anything i try throwing at it segfauklts
2024-02-08 02:36:52 <ptrc> segfaults*
2024-02-08 02:39:19 <ptrc> nevermind
2024-02-08 02:39:33 <ptrc> turns out binfmt somehow cached(?) the qemu-riscv64 executable
2024-02-08 02:39:42 <ptrc> i replaced it with debian's qemu-static-riscv64 and that works just fine
2024-02-08 02:39:55 <ptrc> so it's an issue with our qemu, or perhaps some kind of regression
2024-02-08 02:40:09 <cely> Ok
2024-02-08 02:41:06 <ptrc> yeah
2024-02-08 02:41:11 <ptrc> arch also has 8.2.0
2024-02-08 02:41:16 <ptrc> and it also segfaults
2024-02-08 02:41:26 <omni> !60392
2024-02-08 02:41:32 <ptrc> but debian's 7.2.7 works
2024-02-08 02:41:52 <omni> in case you wanted to do that
2024-02-08 02:41:54 <ptrc> omni: do we really have a lot of packages pending on rv64 though?
2024-02-08 02:42:12 <cely> We are mainly waiting for Rust 1.75.0 to get uploaded
2024-02-08 02:42:17 <ptrc> ohhhhhhh
2024-02-08 02:42:24 <ptrc> then sure, yeah
2024-02-08 02:42:38 <cely> So it can build 1.76.0 that should be out today
2024-02-08 02:42:53 <ptrc> tbf i'm all for weird hacks, as long as they get us going somewhere :p
2024-02-08 02:43:40 <cely> Speaking of weird hacks
2024-02-08 02:43:48 <cely> rpm 4.19.1.1 was released
2024-02-08 02:44:15 <cely> Is there a shell expression to get 4.19?
2024-02-08 02:44:39 <cely> ${pkgver%*.*} worked when it was only 4.19.1
2024-02-08 02:45:46 <ptrc> i don't think so?
2024-02-08 02:46:21 <ptrc> well, as far as i remember, you can remove an arbitrary number of dot segments, but you can't *keep* a number of segments
2024-02-08 02:46:29 <cely> Ok
2024-02-08 02:46:30 <ptrc> not without shelling out to some tool
2024-02-08 02:46:31 <omni> not that I can think of that would work for both 4.19.1 and 4.19.1.1
2024-02-08 02:46:47 <cely> i guess i'll just hard code 4.19 into the source URL for the time being
2024-02-08 02:47:09 <omni> or something sed or awk or something
2024-02-08 02:47:20 <omni> where was it that was done recently?
2024-02-08 02:47:30 <ptrc> cely: better make another variable below pkgver
2024-02-08 02:47:39 <ptrc> makes it easier to spot when upgrading :p
2024-02-08 02:49:26 <cely> Any suggestion for what to call it?
2024-02-08 02:50:26 <omni> or look at main/linux-lts/APKBUILD, for example
2024-02-08 02:50:34 <cely> omni: i don't think using sed or awk in the global scope is encouraged
2024-02-08 02:51:09 <cely> Ah ok, linux-lts uses case to decide
2024-02-08 02:51:16 <cely> Thanks for that suggestion
2024-02-08 02:51:52 <omni> np, thought I had seen something like it somewhere
2024-02-08 02:51:57 <cely> Still, what should i name the variable? _majorver?
2024-02-08 02:53:58 <cely> Wait, using case still doesn't give an expression that returns 4.19 from 4.19.1.1
2024-02-08 02:54:37 <ptrc> cely: ${pkgver%*.*.*}
2024-02-08 02:55:07 <ptrc> or, actually, without the first asterisk
2024-02-08 02:55:55 <cely> Ok thanks
2024-02-08 02:56:52 <omni> with the case you could do something diferent depending on number of digits
2024-02-08 02:58:05 <cely> Yes
2024-02-08 03:01:57 <ptrc> https://gitlab.com/qemu-project/qemu/-/issues/1908
2024-02-08 03:01:59 <ptrc> perhaps related?
2024-02-08 03:04:41 <omni> I'll get that fake downgrade in
2024-02-08 03:08:40 <cely> hehe, at least we have Rust 1.75.0 on riscv64 now
2024-02-08 03:12:19 <omni> !60394 to keep track of it
2024-02-08 03:13:36 <ptrc> thank you both for carrying out this massive rust upgrade chain <3
2024-02-08 03:13:36 <ptrc> oh, btw, because i didn't get the chance to do so yet
2024-02-08 03:13:55 <cely> You're welcome
2024-02-08 03:14:11 <cely> Thanks to omni too for helping out
2024-02-08 03:15:07 <cely> omni would get the MR in proper shape for merging, while i tried out the next Rust version :)
2024-02-08 03:15:46 <omni> yeah, team effort
2024-02-08 03:16:34 <cely> !60393 in case anyone is interested in how i did the pkgver thing
2024-02-08 03:17:11 <cely> Also, why is abuild complaining that "popt-dev should be removed from depends_dev"?
2024-02-08 03:17:55 <omni> and when they release version 5?
2024-02-08 03:18:55 <cely> Hmm, i guess the "popt-dev" thing is due to pc:popt being auto-traced
2024-02-08 03:18:58 <ptrc> cely: it's auto-traced from the pc:
2024-02-08 03:18:59 <ptrc> yeah
2024-02-08 03:21:33 <cely> https://ftp.osuosl.org/pub/rpm/releases/historical/rpm-3.0.x/
2024-02-08 03:21:42 <cely> So they have historically done an rpm-3.0 release
2024-02-08 03:21:59 <cely> and 4.0 as well, guess i better account for that
2024-02-08 03:25:06 <cely> Hopefully when they do get to 5, they release it as 5.0 or 5.0.something, and not just 5
2024-02-08 03:25:09 <cely> :D
2024-02-08 03:28:06 <omni> 𝍸.🁐
2024-02-08 03:28:36 <ptrc> https://ptrc.gay/gRjnkBoY
2024-02-08 03:28:40 <ptrc> omni: is your terminal okay? :p
2024-02-08 03:28:57 <ptrc> ( mostly just curious where are those coming from )
2024-02-08 03:29:04 <omni> perfectly fine, does that not render at your end?
2024-02-08 03:29:24 <ptrc> it renders just as on the screenshot
2024-02-08 03:29:29 <cely> i see .<dice>
2024-02-08 03:29:36 <cely> not the thing before the .
2024-02-08 03:29:51 <ptrc> the second one is a domino piece
2024-02-08 03:30:07 <ptrc> and the first is.. "TALLY MARK FIVE" according to unicode
2024-02-08 03:30:13 <cely> Ah right, domino
2024-02-08 03:30:39 <omni> I'm just looking into the future of version numbering
2024-02-08 03:30:57 <omni> uni print all | sk -e | cut -d \' -f 2 | wl-copy -p -n
2024-02-08 03:31:25 <omni> is what I'm using to search for various fun unicode
2024-02-08 03:31:27 <ptrc> oh lol
2024-02-08 03:31:33 <cely> Is that how you found your Github profile description?
2024-02-08 03:33:00 <omni> https://github.com/omnivagant ?
2024-02-08 03:33:17 <cely> "The wanderer"
2024-02-08 03:33:35 <omni> ah, yes
2024-02-08 03:33:52 <omni> forgot about that
2024-02-08 03:34:01 <cely> :)
2024-02-08 03:36:43 <cely> When broken into components, it's literally fire over mountain, so i was wondering what was up with that until i checked wikipedia and saw its unicode name
2024-02-08 06:18:07 <cely> algitbot: retry master
2024-02-08 06:24:27 <cely> algitbot: retry master
2024-02-08 06:30:25 <cely> algitbot: retry master
2024-02-08 06:36:58 <cely> algitbot: retry master
2024-02-08 06:42:36 <cely> algitbot: retry master
2024-02-08 06:50:29 <cely> algitbot: retry master
2024-02-08 07:05:57 <cely> algitbot: retry master
2024-02-08 07:12:19 <cely> algitbot: retry master
2024-02-08 07:26:29 <ptrc> \o/
2024-02-08 07:48:05 <cely> https://github.com/rust-lang/blog.rust-lang.org/pull/1243 Rust 1.76.0 announcement has been prepared
2024-02-08 07:51:20 <cely> According to https://forge.rust-lang.org/release/process.html#release-day-thursday that announcement blog post will be merged "T-2m"
2024-02-08 12:36:21 <cely> Still no sign of Rust 1.76.0..i wonder if it will be 2024-02-09 for me when that is released
2024-02-08 14:42:53 <celie> omni: https://blog.rust-lang.org/2024/02/08/Rust-1.76.0.html it's been released
2024-02-08 14:43:50 <celie> but i'll be going AFK, so will check the status of your MR tomorrow (if it's not already merged by then)
2024-02-08 14:46:02 <omni> celie: already saw
2024-02-08 14:46:13 <omni> but thanks!
2024-02-08 14:49:52 <omni> celie: it's merged now ;)
2024-02-08 19:03:10 <omni> \o/
2024-02-08 19:26:22 <koshershekels> https://appealforassistance.notion.site/Appeal-for-Assistance-abcca31346e944b38e09ebabb4208152
2024-02-08 21:04:06 <omni> algitbot: retry master
2024-02-08 21:17:51 <omni> algitbot: retry 3.19-stable
2024-02-09 00:36:16 <omni> cool
2024-02-09 00:42:27 <ptrc> omni: funnily enough, the solution was already linked there, i just didn't notice that it's for pcre2 that we already have lol
2024-02-09 01:42:53 <celie> So, the QEMU segfaulting issue was actually a pcre2 issue?
2024-02-09 01:45:35 <celie> Anyway, since it's fixed, i should go retry the OCaml 5.2 CI on riscv64, maybe it will finally complete successfully
2024-02-09 01:46:12 <ptrc> celie: yup, but *technically* also a qemu issue
2024-02-09 01:50:04 <celie> Oh wow, some activity from @ScrumpyJack (#15766)
2024-02-09 01:54:11 <celie> and the reply for that package request is that it's pretty much undoable, hehe
2024-02-09 01:54:35 <celie> Anyway, has there ever been an attempt at packaging rust-nightly?
2024-02-09 01:59:32 <omni> not that I know of
2024-02-09 01:59:53 <omni> what would it be for?
2024-02-09 02:00:11 <celie> ayakael: There's an updated apkbuild-cpan at https://gitlab.alpinelinux.org/alpine/abuild , i think you should use that to create perl-email-valid and perl-net-domain-tld in !60477
2024-02-09 02:00:34 <omni> to be ahead of and prepared for releases?
2024-02-09 02:01:06 <celie> omni: Yes :)
2024-02-09 02:01:13 <celie> ayakael: since you made me aware of that MR
2024-02-09 02:03:42 <omni> since this latest rust upgrade I thought it was really nice to try with a beta first like that
2024-02-09 02:03:58 <omni> but how do I know where to get one?
2024-02-09 02:04:26 <celie> Well, with nightly we would get to prepare 2 releases ahead :)
2024-02-09 02:05:02 <omni> yeah...
2024-02-09 02:05:07 <celie> and i've realized something
2024-02-09 02:05:22 <omni> that you want to maintain rust? ;)
2024-02-09 02:05:35 <celie> When you asked for a Rust that would be close to 1.76.0, and i gave you beta9
2024-02-09 02:05:48 <celie> There's actually something better
2024-02-09 02:06:16 <omni> the suspense
2024-02-09 02:06:28 <celie> A pre-release: https://blog.rust-lang.org/inside-rust/2024/02/04/1.76.0-prerelease.html
2024-02-09 02:06:43 <celie> So, i guess there is a reason for everything
2024-02-09 02:07:07 <celie> The day Rust beta became 1.77.0 was the day Rust 1.76.0 got a prerelease
2024-02-09 02:07:43 <celie> i was wonder if Rust 1.76.0 got moved to a secret repo for its last few days before release
2024-02-09 02:07:47 <celie> wondering*
2024-02-09 02:08:17 <celie> (as it's in none of the normal release channels: stable, beta, nightly)
2024-02-09 02:08:36 <omni> ok, I found that release page too, when looking for where to get 1.77.0-beta tarballs after I had merged 1.76.0
2024-02-09 02:08:41 <celie> but just turns out it got moved to dev-static.rust-lang.org, which i think is used to test rustup
2024-02-09 02:09:28 <celie> For 1.77.0, you may try the latest Rust beta
2024-02-09 02:10:32 <celie> From memory, there will be a reference to the latest date in https://static.rust-lang.org/dist/channel-rust-beta.toml
2024-02-09 02:10:35 <omni> is my mistake looking for a 1.77.0 beta and not just a beta?
2024-02-09 02:10:54 <celie> What do you mean?
2024-02-09 02:11:54 <celie> Beta is now tracking what will eventually become 1.77.0, and will probably continue to do so until it becomes a prerelease (in which case 1.78 would be "promoted" to beta)
2024-02-09 02:12:18 <omni> I've been searching the web for rust 1.77.0 beta, I should just have searched for rust beta
2024-02-09 02:12:33 <omni> yeah, I think I'm catching on
2024-02-09 02:13:09 <omni> but that toml file was a good resource
2024-02-09 02:15:20 <celie> As for maintaining Rust, i've been thinking, maybe i wouldn't mind, if i can have rust-nightly to help flush out any issues before it hits stable, and of course your help in getting Rust stable merged (i'm not exactly a fan of aligning patches and then re-extracting 2GB's worth of files to see if the aligning worked ;))
2024-02-09 02:19:52 <omni> I was thinking of it myself after merging 1.76.0, fueled by how easy that seemed to be
2024-02-09 02:20:55 <omni> but I've also been thinking if maintaining rust could/should be shared
2024-02-09 02:21:10 <celie> i guess catching issues early is good, the Github pull request that i reverted to solve the 32-bit RAM issue is 6 months old
2024-02-09 02:21:24 <celie> s/RAM/ARM/
2024-02-09 02:21:26 <celie> haha
2024-02-09 02:21:59 <ptrc> omni: if you're gonna start a rust team in alpine, count me in :p
2024-02-09 02:22:04 <celie> Maintaining lots of things could benefit from being shared
2024-02-09 02:22:43 <ptrc> ( still kinda grumpy that free edition of gitlab doesn't have proper team support when it comes to stuff like MR reviews )
2024-02-09 02:22:49 <omni> also for getting upgrades/changes in
2024-02-09 02:22:54 <omni> ptrc: sure!
2024-02-09 02:23:43 <omni> but we can kinda deal with team things anyway, can't we?
2024-02-09 02:25:00 <ptrc> yeah, the bot makes things a bit easier
2024-02-09 02:30:03 <cely> i wonder if this channel is becoming #alpine-rust
2024-02-09 02:30:56 <ptrc> more like #alpine-build-failures :p
2024-02-09 02:31:11 <cely> (would probably be good to have a channel, if a team for it is started)
2024-02-09 02:49:04 <omni> yeah
2024-02-09 02:50:29 <cely> i think OCaml 5.2 has proceeded further then it previously did before the QEMU/pcre2 fix was merged
2024-02-09 02:50:45 <cely> Let's hope it continues till the end
2024-02-09 02:50:48 <cely> s/then/than/
2024-02-09 02:52:50 <cely> Oops, it failed
2024-02-09 02:53:35 <cely> "Illegal instruction", and i spoke too soon, looks like it's still failing at the same spot
2024-02-09 02:55:04 <cely> https://gitlab.alpinelinux.org/Celeste/aports/-/jobs/1271208 in case anyone is interested
2024-02-09 02:55:22 <cely> Anyway, i guess it is back to using the bytecode compiler for riscv64
2024-02-09 02:57:20 <cely> So for OCaml 5.2 now we have a tie between architectures having a native compiler (x86_64, aarch64, s390x, and the newly re-added ppc64le), and a bytecode compiler (armhf, armv7, riscv64, and x86)
2024-02-09 02:59:24 <omni> could we add it as ocaml5 for now?
2024-02-09 02:59:38 <cely> What do you mean?
2024-02-09 02:59:39 <omni> to have it available but not move from ocaml 4 just yet
2024-02-09 02:59:50 <cely> It is testing/ocaml5
2024-02-09 03:00:07 <cely> but version 5.2 is currently in alpha
2024-02-09 03:00:15 <omni> oh, I'm tired and haven't thought about this for a while
2024-02-09 03:01:06 <cely> Currently, it has an unversioned `provides=ocaml`
2024-02-09 03:01:16 <cely> i wonder if that should just be removed
2024-02-09 03:01:36 <cely> since 4 and 5 are not really interchangeable
2024-02-09 03:02:16 <cely> as in, OCaml 4 aports wanting `ocaml` cannot simply use OCaml 5
2024-02-09 03:02:51 <cely> and it is unversioned anyway, so apk will not auto-select it
2024-02-09 03:03:54 <cely> (even if you comment out community in /etc/apk/repositories where OCaml 4 is)
2024-02-09 03:06:34 <omni> I need to get back to thinking about that some other time
2024-02-09 03:11:21 <omni> look at it fail !60488
2024-02-09 03:11:32 <omni> time to give up
2024-02-09 03:12:30 <cely> Ah!
2024-02-09 03:12:30 <cely> lol
2024-02-09 03:12:42 <cely> i actually have a patch for that
2024-02-09 03:12:54 <cely> Let me see if i can dig it up
2024-02-09 03:13:21 <cely> (could've been rebased away in one of my branches)
2024-02-09 03:15:26 <omni> did you push it at any time?
2024-02-09 03:16:29 <omni> also not sure about need-ssp_nonshared.patch, but library/std/src/sys/unix/mod.rs is gone
2024-02-09 03:16:37 <omni> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/60488/diffs#diff-content-8336ac0830e2405a5d72e350241622a935e85e81
2024-02-09 03:16:40 <cely> Sure, but i have the bad habit of reusing old branches to test CI
2024-02-09 03:17:02 <cely> Let me get you the patch for that as well
2024-02-09 03:17:39 <omni> I think I need to look at it at a later time
2024-02-09 03:17:48 <omni> but comment here or in the MR
2024-02-09 03:18:18 <cely> https://gitlab.alpinelinux.org/Celeste/aports/-/blob/45c8c7d8e3/main/rust/no-rustfmt-dist-file.patch
2024-02-09 03:18:39 <cely> You will probably need to amend the "date" field
2024-02-09 03:22:20 <omni> check
2024-02-09 03:22:23 <cely> https://gitlab.alpinelinux.org/Celeste/aports/-/commit/22c5da5ccf
2024-02-09 03:22:26 <omni> 1970-01-01
2024-02-09 03:22:40 <cely> My changes from when i accidentally used 1.77.0 thinking it was a 1.76.0 beta
2024-02-09 03:23:54 <cely> The file in need-ssp_nonshared.patch has been renamed from library/std/src/sys/unix/mod.rs to library/std/src/sys/pal/unix/mod.rs
2024-02-09 03:24:17 <cely> and bootstrap-vendor-remap.patch has been upstreamed
2024-02-09 03:26:37 <cely> i see you've already handled bootstrap-vendor-remap.patch in your MR
2024-02-09 03:36:12 <cely> Hmm, it seems the OCaml developers have mostly rejected the PR to add loongarch support due to it being similar to riscv64, and also not having enough resources to support this architecture
2024-02-09 03:37:24 <cely> i wonder if we'll be patching that in once we add loongarch to our list of supported architectures
2024-02-09 11:00:55 <omni> ouch, I'll look at that in an hour or two
2024-02-09 18:44:29 <omni> I'm looking at that issue in !60524
2024-02-10 02:42:16 <omni> if we were to create a team/rust, I wonder if it shouldn't also be the custodian of rust-analyzer and, or at least, cargo-auditable
2024-02-10 02:52:10 <cely> I think Kladky was almost 1 step away from claiming main/rust in !60344
2024-02-10 02:53:35 <cely> and now they're claiming cargo-auditable and rust-analyzer :)
2024-02-10 03:09:29 <cely> algitbot: retry master
2024-02-10 03:10:08 <cely> algitbot: retry master
2024-02-10 03:11:29 <cely> Hmm, so all the 3 and 21 other aports currently blocked in s390x and riscv64 are revdeps of fgt and libjxl?
2024-02-10 03:14:40 <omni> yes
2024-02-10 03:14:45 <omni> fgt I haven't looked at
2024-02-10 03:16:09 <omni> the other I'm looking at in !60524 and !6534
2024-02-10 03:16:19 <omni> uhm, no..
2024-02-10 03:16:28 <omni> !60534
2024-02-10 03:16:38 <omni> ther we go
2024-02-10 03:17:02 <omni> so, in the second one I'm rebuilding llvm17 and lld to look at the test output, I think
2024-02-10 03:17:08 <omni> it's taking so long...
2024-02-10 03:17:36 <omni> to compare with test output from the first one before I disabled tests for llvm17 with the patch
2024-02-10 03:20:16 <cely> Alright
2024-02-10 03:26:40 <omni> you're welcome to have a look if you want
2024-02-10 03:46:33 <cely> Ah that's why i couldn't get a riscv64 CI :)
2024-02-10 03:46:45 <cely> both these MRs are running that
2024-02-10 23:06:40 <andypost[m]> algitbot: retry master
2024-02-11 00:40:27 <omni> algitbot: retry master
2024-02-11 03:08:25 <omni> ptrc: !60624
2024-02-11 03:09:04 <ptrc> thanks!
2024-02-11 03:09:20 <omni> np
2024-02-11 03:10:17 <cely> Regarding mcookie
2024-02-11 03:10:31 <cely> Did you have a look at what requires that?
2024-02-11 03:10:34 <cely> Is it xvfb?
2024-02-11 03:12:03 <cely> or more specifically, xvfb-run
2024-02-11 03:12:13 <cely> Line 155 of /usr/bin/xvfb-run?
2024-02-11 03:13:47 <cely> Yes, just looked at the error log on build.a.o
2024-02-11 03:13:57 <cely> Perhaps mcookie should be added to xvfb-run instead?
2024-02-11 03:15:12 <omni> I only looked at the error message, that it was used when profiling firefox, that is only run for aarch64|x86_64|ppc64le, saw that it was installed during CI build but not package build and that no changes had been made to xvfb-run recently
2024-02-11 03:16:01 <omni> I also remembered seeing mcookie being added to a checkdepends recently
2024-02-11 03:17:21 <omni> cely: ah, that was you 47ee2076d35f6004fbbb2bb22f100c534c53287a
2024-02-11 03:18:39 <cely> Hmm, i just tested one of my aports that uses xvfb-run for tests (perl-tkx)
2024-02-11 03:18:45 <cely> and now it fails to find mcookie
2024-02-11 03:19:59 <omni> wait
2024-02-11 03:20:14 <cely> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/perl-tkx/perl-tkx-1.10-r0.log
2024-02-11 03:20:33 <cely> mcookie was installed when it built on the builders
2024-02-11 03:21:35 <omni> something was changed recently..
2024-02-11 03:22:44 <cely> I wonder what changed
2024-02-11 03:24:00 <omni> less things depend on xinit... 1fd2d70696b88a0605ad5771137da148c998c192
2024-02-11 03:24:07 <omni> xinit depend on mcookie
2024-02-11 03:24:14 <omni> but could that really be it?
2024-02-11 03:24:28 <omni> for firefox maybe
2024-02-11 03:26:12 <cely> Yes, that's probably it
2024-02-11 03:26:17 <omni> but looking at the xvfb-run script, it looks like it should depend on mcookie, doesn't it?
2024-02-11 03:27:39 <cely> Yes
2024-02-11 03:28:49 <cely> xvfb is a subpackage of community/xorg-server, and so inherits its depends=
2024-02-11 03:29:12 <cely> which is why mcookie is no longer installed
2024-02-11 03:32:36 <omni> 👍
2024-02-11 03:32:43 <omni> I'm working on an MR
2024-02-11 03:33:06 <cely> I wonder what else could be broken as a result of removing xinit as dependency
2024-02-11 03:36:37 <omni> yes... 
2024-02-11 03:36:59 <omni> any issues about it?
2024-02-11 03:38:05 <cely> Not sure, the MR removing the xinit dep did get a thumbs down
2024-02-11 03:41:07 <cely> tigervnc already depends on xinit, so that's taken care of
2024-02-11 03:41:37 <cely> (I'm guessing the things that could break are scripts like xvfb-run)
2024-02-11 03:44:45 <cely> startx is a part of xinit itself, and sx seems to use only xauth, which is in its depends=
2024-02-11 03:47:45 <omni> is there any way to see when a 👎 ?
2024-02-11 03:48:14 <omni> thinking it may have been a reaction to what it led to
2024-02-11 03:49:17 <cely> What do you mean? A search filter to list all MRs with thumbs-downs?
2024-02-11 03:50:31 <omni> I mean that I haven't managed to see when in time someone gave an MR a thumbs down or up and was wondering if there was a way
2024-02-11 03:50:31 <cely> or do you mean finding the timestamp for the thumbs-down?
2024-02-11 03:50:45 <omni> doesn't matter much
2024-02-11 03:51:13 <omni> I think I'm gonna merge !60625 now, would you like to have a quick peek?
2024-02-11 03:51:45 <omni> of course it's building all the things
2024-02-11 03:52:04 <cely> The Gitlab API could show you the time of the emoji reaction
2024-02-11 03:52:17 <cely> I've looked, it looks good
2024-02-11 03:52:26 <cely> So, it seems gajim also encountered this issue
2024-02-11 03:52:29 <omni> great, let's
2024-02-11 03:56:10 <omni> lomiri-content-hub too, do you see any more?
2024-02-11 03:59:53 <cely> No, don't see anything else
2024-02-11 04:06:04 <omni> I wonder if anything else broke
2024-02-11 04:07:00 <omni> I'm all for removing dependencies
2024-02-11 04:07:04 <cely> and it seems Rust 1.77.0 beta has passed CI for a couple of archs
2024-02-11 04:07:12 <omni> w00t
2024-02-11 04:08:26 <cely> On x86_64: "Size difference for rust: 560 MiB -> 524 MiB"
2024-02-11 04:09:03 <cely> I wonder if that's just due to the beta having less things included, but probably not
2024-02-11 05:15:52 <cely> Another MR affected by missing mcookie: !60630
2024-02-11 05:16:50 <cely> 
ACTION puts it into draft for the time being while waiting for aarch64 and ppc64le to get the fixed xvfb-run

2024-02-11 05:19:26 <cely> algitbot: retry master
2024-02-11 05:45:41 <cely> algitbot: retry master
2024-02-11 05:46:35 <cely> Finally, the builders are building something else that doesn't depend on fgt and libjxl
2024-02-11 05:47:17 <cely> Hopefully, one or two more retries will further cut down the number of pending aports
2024-02-11 05:47:22 <cely> algitbot: retry master
2024-02-11 05:47:55 <cely> algitbot: retry master
2024-02-11 05:49:26 <cely> algitbot: retry master
2024-02-11 05:51:05 <cely> algitbot: retry master
2024-02-11 05:52:24 <cely> I guess that's it
2024-02-11 12:43:56 <cely> omni: I would say yes to your question in !60477
2024-02-11 12:52:40 <omni> I assumed so, it was also a way of pingingthem
2024-02-11 13:13:48 <omni> mmm... cookies... https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/60586/diffs?diff_id=877087&start_sha=653676758d95c5082853e5e41336934d33ad827c
2024-02-11 13:28:22 <cely> algitbot: retry master
2024-02-11 13:33:46 <cely> algitbot: retry master
2024-02-11 13:57:12 <cely> "QSYSTEM: InstallationTest::testInstallCommand() kf.newstuff.core: Could not determine type of archive file '"/tmp/PNdHti-testfile.txt"'"
2024-02-11 13:57:14 <cely> algitbot: retry master
2024-02-11 14:02:35 <omni> 
ACTION hopes jirutka will take time to look at !54061

2024-02-11 14:15:01 <cely> algitbot: retry master
2024-02-11 14:34:38 <cely> algitbot: retry master
2024-02-11 15:19:13 <celie> algitbot: retry master
2024-02-11 15:23:12 <celie> algitbot: retry master
2024-02-11 15:24:32 <celie> algitbot: retry master
2024-02-11 15:25:13 <celie> Ha, there's still frameworkintegration5 that isn't blocked by fgt that s390x can build
2024-02-11 15:25:58 <celie> Probably nothing left, but one more last retry
2024-02-11 15:26:31 <celie> algitbot: retry master
2024-02-11 15:27:06 <celie> Now it's building plasma-framework5
2024-02-11 15:29:28 <celie> and krunner5 and postgresql13
2024-02-11 15:29:38 <celie> So, i wonder how many aports are actually blocked by fgt on s390x
2024-02-11 15:31:53 <celie> Looking through the log, i mentioned 3 aports
2024-02-11 15:35:29 <celie> i mean, just the number 3, didn't look further into which aports specifically
2024-02-11 15:35:47 <celie> algitbot: retry master
2024-02-11 15:36:21 <celie> algitbot: retry master
2024-02-11 15:39:10 <celie> algitbot: retry master
2024-02-11 15:41:42 <omni>         390x) ctest --test-dir build --output-on-failure -E "cluster";;
2024-02-11 15:41:54 <omni> could it be that it is failing due to that?
2024-02-11 15:42:17 <celie> fgt?
2024-02-11 15:42:29 <omni> wait, that case statement is wrong
2024-02-11 15:42:30 <celie> algitbot: retry master
2024-02-11 15:42:40 <omni> it should be s390x, not 390x
2024-02-11 15:42:47 <omni> *sigh*
2024-02-11 15:42:48 <celie> Yes
2024-02-11 15:42:59 <omni> I'll fix
2024-02-11 15:43:11 <omni> but how did it pass in CI?
2024-02-11 15:43:20 <celie> You initially thought it was failing because it executed that?
2024-02-11 15:43:48 <omni> no, because it was missing something because that was excluded
2024-02-11 15:44:07 <omni> like a test depending on something with that test, idk
2024-02-11 15:44:20 <celie> Ah yes, cluster fails, looking at the build log
2024-02-11 15:44:20 <celie> lol
2024-02-11 15:44:37 <celie> So, we were sitting here wondering what was wrong but never looked deeper
2024-02-11 15:46:49 <celie> I think the s390x CI was skipped for !60517
2024-02-11 15:47:31 <celie> and then the commit disabling the failing test was merged without going through CI
2024-02-11 15:48:00 <celie> So, nobody caught the typo until now :)
2024-02-11 15:48:46 <celie> Yay, it's finally fixed now
2024-02-11 15:48:54 <omni> \o/
2024-02-11 15:49:15 <omni> I didn't look deeper because I thought Bart should fix it and not just leave it like that
2024-02-11 15:49:41 <ikke> nice work
2024-02-11 15:49:46 <celie> I wonder how many aports in testing s390x will need to catch up with
2024-02-11 15:49:48 <omni> I did poke him about it as soon after it showed up
2024-02-11 15:50:06 <celie> and he must have thought he'd already fixed it
2024-02-11 15:51:54 <omni> yeah, sure, but he should also know to keep an eye at https://build.alpinelinux.org/
2024-02-11 15:54:51 <PureTryOut> Huh I did believe I already resolved it. It was a test that used to be disabled on s390x which I re-enabled. I just disabled it again
2024-02-11 15:55:40 <omni> you missed the s in s390x =)
2024-02-11 16:25:51 <celie> algitbot: retry master
2024-02-11 16:36:29 <celie> algitbot: retry master
2024-02-12 04:48:27 <cely> The s390x CI seems to be acting up again
2024-02-12 13:41:33 <cely> algitbot: retry master
2024-02-12 13:43:25 <cely> algitbot: retry master
2024-02-12 14:13:30 <omni> finger crossings
2024-02-12 14:14:12 <cely> :)
2024-02-12 14:18:37 <cely> algitbot: retry master
2024-02-12 14:41:25 <cely> algitbot: retry master
2024-02-12 14:47:44 <cely> algitbot: retry master
2024-02-12 16:02:35 <cely> algitbot: retry master
2024-02-12 16:04:36 <cely> algitbot: retry master
2024-02-13 04:13:13 <cely> algitbot: retry master
2024-02-13 04:15:06 <cely> algitbot: retry master
2024-02-13 04:56:02 <cely> algitbot: retry master
2024-02-13 04:57:37 <cely> algitbot: retry master
2024-02-13 08:28:44 <cely> algitbot: retry master
2024-02-13 08:37:03 <cely> algitbot: retry master
2024-02-13 08:39:30 <cely> algitbot: retry master
2024-02-13 11:46:25 <cely> algitbot: retry master
2024-02-13 17:00:42 <omni> algitbot: retry master
2024-02-13 22:50:26 <omni> algitbot: retry master
2024-02-13 23:51:32 <omni> uh-oh
2024-02-13 23:54:18 <omni> so the checksum shouldn't have been changed becaue it's cached
2024-02-14 02:40:20 <omni> now what
2024-02-14 02:42:02 <omni> gah
2024-02-14 02:42:10 <omni> I was about to afk
2024-02-14 02:43:03 <cely> Hmm
2024-02-14 02:43:18 <cely> Does it need bash back in checkdepends?
2024-02-14 02:46:21 <omni> hmm.. maybe..
2024-02-14 02:46:38 <cely> It's SIGSEGV though
2024-02-14 02:47:06 <omni> yeah, just checked on a CI build and bash wasn't installed there...
2024-02-14 02:47:30 <cely> Bash was just removed with this upgrade
2024-02-14 02:49:37 <cely> I wonder if bash is installed on the CI runners, but probably not
2024-02-14 02:49:43 <omni> yes, but tests were run in CI three days ago
2024-02-14 02:50:26 <cely> Usually it's the builders that have more packages installed than the CI runners (probably because CI uses a Docker image, so easier to trim down the packages installed there)
2024-02-14 02:50:46 <cely> Did we have a Rust upgrade in between the runs on CI and builder?
2024-02-14 02:51:43 <cely> Yes we did
2024-02-14 02:52:04 <omni> wasn't that earlier?
2024-02-14 02:52:04 <cely> 3 days ago was for riscv64, which didn't complete tests
2024-02-14 02:52:09 <cely> The other archs was 6 days ago
2024-02-14 02:52:32 <omni> ah
2024-02-14 02:53:12 <cely> So, Rust 1.74.1 vs 1.76.0
2024-02-14 02:53:13 <omni> looks like it built with rust 1.74.1
2024-02-14 02:53:43 <cely> At least we can rule out llvm16
2024-02-14 02:55:13 <cely> algitbot: retry master
2024-02-14 02:58:41 <cely> algitbot: retry master
2024-02-14 03:00:18 <omni> since it failed the same way, I think, on all the builders, my expectations are low
2024-02-14 03:00:35 <cely> Yeah, same here
2024-02-14 03:02:49 <cely> algitbot: retry master
2024-02-14 03:04:54 <cely> algitbot: retry master
2024-02-14 03:06:11 <cely> Results should be coming in any time now
2024-02-14 03:06:58 <omni> the only thing I can think of right now is to just disable the tests
2024-02-14 03:07:27 <omni> because I can't stay much longer now
2024-02-14 03:07:51 <cely> Just nu-path or !check?
2024-02-14 03:08:40 <cely> Did it just pass on armhf?
2024-02-14 03:09:52 <cely> and aarch64 too
2024-02-14 03:10:14 <cely> Flaky tests will be flaky
2024-02-14 03:10:23 <cely> algitbot: retry master
2024-02-14 03:11:19 <omni> oh, ok..
2024-02-14 03:11:42 <cely> algitbot: retry master
2024-02-14 03:12:05 <cely> I guess i'll keep retrying for a while, at least 2 ARM's are now unblocked
2024-02-14 03:12:13 <cely> So you can go AFK if you want
2024-02-14 03:12:48 <omni> are you sure?
2024-02-14 03:12:49 <cely> algitbot: retry master
2024-02-14 03:13:17 <omni> I mean, that it's fine to sit and do that
2024-02-14 03:13:18 <cely> Is anything certain when it comes to software? :D
2024-02-14 03:13:28 <cely> algitbot: retry master
2024-02-14 03:13:33 <cely> Keep retrying?
2024-02-14 03:13:40 <omni> yeah
2024-02-14 03:13:46 <cely> Most probably yes, maybe for the next half an hour or so
2024-02-14 03:14:37 <omni> because I almost clicked "Create merge request" on one that would !check
2024-02-14 03:14:44 <cely> hehe
2024-02-14 03:14:56 <cely> algitbot: retry master
2024-02-14 03:15:07 <cely> Maybe that's fine too
2024-02-14 03:15:30 <omni> I created it
2024-02-14 03:15:32 <cely> We'll just let this run determine whether it's built with this commit or the new one
2024-02-14 03:15:45 <omni> !60811
2024-02-14 03:16:18 <cely> algitbot: retry master
2024-02-14 03:17:33 <omni> as a compromise, ask someone to merge the above when you give up
2024-02-14 03:18:08 <cely> Alright
2024-02-14 03:18:16 <omni> <3
2024-02-14 03:18:26 <cely> Bye
2024-02-14 03:18:27 <omni> *poff*
2024-02-14 03:19:40 <cely> algitbot: retry master
2024-02-14 03:21:17 <cely> algitbot: retry master
2024-02-14 03:24:42 <cely> algitbot: retry master
2024-02-14 03:25:03 <cely> Now armv7 has passed :)
2024-02-14 03:26:00 <cely> Hopefully at least one of the x86* will pass next
2024-02-14 03:28:51 <ptrc> algitbot: retry master
2024-02-14 03:30:45 <cely> Hi ptrc, !59032 should be ready. However, the x86_64 CI is busy building Chromium or something
2024-02-14 03:32:21 <cely> Looks like it's is only x86_64 left that hasn't finished nushell :)
2024-02-14 03:32:32 <cely> s/is//
2024-02-14 03:39:40 <cely> algitbot: retry master
2024-02-14 03:41:03 <cely> algitbot: retry master
2024-02-14 03:42:32 <cely> Hmm, Nushell on x86_64 is taking a little longer this time, hopefully that's a good sign (that it's finishing all the tests)
2024-02-14 03:43:19 <cely> Apparently, not
2024-02-14 03:43:20 <cely> algitbot: retry master
2024-02-14 03:43:27 <cely> algitbot: retry master
2024-02-14 03:45:15 <cely> algitbot: retry master
2024-02-14 03:46:42 <cely> algitbot: retry master
2024-02-14 03:49:01 <cely> algitbot: retry master
2024-02-14 03:52:35 <cely> algitbot: retry master
2024-02-14 03:53:57 <cely> algitbot: retry master
2024-02-14 03:58:31 <cely> \o/
2024-02-14 03:58:33 <cely> algitbot: retry master
2024-02-14 04:00:34 <cely> algitbot: retry master
2024-02-14 04:04:30 <cely> algitbot: retry master
2024-02-14 04:06:01 <cely> algitbot: retry master
2024-02-14 05:09:27 <iggy> https://github.com/llvm/llvm-project/issues/64102 ?
2024-02-14 08:50:23 <ptrc> iggy: exactly that one, yes
2024-02-14 08:51:25 <ptrc> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/60608
2024-02-14 16:19:03 <omni> I was about to merge that!
2024-02-14 16:19:06 <omni> :D
2024-02-14 16:20:32 <omni> ptrc: btw, I'm holding off with !60793 until build-edge-x86_64 is done with chromium
2024-02-14 16:21:07 <ptrc> alrighty, makes sense
2024-02-14 16:21:25 <ptrc> ( are those the same machine? i always forget )
2024-02-14 16:21:30 <ikke> yes
2024-02-14 16:21:38 <ikke> we usually have a single machine per arch
2024-02-14 16:21:52 <ikke> (and a separate CI host if available)
2024-02-14 16:25:48 <cely> :O
2024-02-14 16:26:11 <cely> algitbot: retry master
2024-02-14 16:26:39 <cely> "process out of memory"
2024-02-14 16:26:39 <cely> Hmm
2024-02-14 16:26:43 <omni> yes
2024-02-14 16:29:26 <omni> algitbot: retry master
2024-02-14 16:32:26 <cely> algitbot: retry master
2024-02-14 16:35:27 <cely> algitbot: retry master
2024-02-14 17:02:28 <cely> algitbot: retry master
2024-02-14 17:13:25 <omni> #x86, armv7: webpack: JavaScript heap out of memory
2024-02-14 17:13:30 <omni> arch="noarch !riscv64 !x86 !armv7"
2024-02-14 17:13:37 <omni> maybe disable on armhf too
2024-02-14 17:40:14 <omni> !59991
2024-02-14 18:17:27 <omni> algitbot: retry master
2024-02-15 02:16:47 <celie> algitbot: retry master
2024-02-15 02:18:18 <celie> algitbot: retry master
2024-02-15 02:21:10 <celie> algitbot: retry master
2024-02-15 02:23:03 <celie> algitbot: retry master
2024-02-15 02:42:46 <cely> algitbot: retry master
2024-02-15 02:43:44 <cely> I was hoping riscv64 would start compiling nodejs-current, but instead it gets quickjs :)
2024-02-15 02:56:16 <cely> algitbot: retry master
2024-02-15 02:57:35 <cely> algitbot: retry master
2024-02-15 02:59:12 <cely> algitbot: retry master
2024-02-15 03:08:39 <cely> algitbot: retry master
2024-02-15 03:18:55 <cely> algitbot: retry master
2024-02-15 03:24:49 <cely> algitbot: retry master
2024-02-15 03:26:16 <cely> algitbot: retry master
2024-02-15 15:03:31 <cely> algitbot: retry master
2024-02-15 15:06:29 <cely> algitbot: retry master
2024-02-16 01:18:46 <celie> algitbot: retry master
2024-02-16 02:21:51 <cely> algitbot: retry master
2024-02-16 02:28:35 <cely> algitbot: retry master
2024-02-16 02:42:50 <cely> algitbot: retry master
2024-02-16 03:02:45 <andypost[m]> algitbot: retry master
2024-02-16 03:03:44 <andypost[m]> algitbot: retry master
2024-02-16 03:37:25 <cely> algitbot: retry master
2024-02-16 03:41:00 <cely> algitbot: retry master
2024-02-16 04:04:48 <cely> algitbot: retry master
2024-02-16 04:12:10 <cely> algitbot: retry master
2024-02-16 04:19:40 <cely> algitbot: retry master
2024-02-16 04:25:35 <cely> algitbot: retry master
2024-02-16 04:28:45 <cely> algitbot: retry master
2024-02-16 04:31:44 <cely> algitbot: retry master
2024-02-16 04:46:27 <cely> algitbot: retry master
2024-02-16 04:49:08 <cely> algitbot: retry master
2024-02-16 05:57:35 <cely> algitbot: retry master
2024-02-16 06:01:48 <celie> algitbot: retry master
2024-02-16 06:29:38 <cely> algitbot: retry master
2024-02-16 06:37:31 <cely> algitbot: retry master
2024-02-16 09:27:46 <PureTryOut> I'm working on the gwenview build failures
2024-02-16 12:21:21 <cely> algitbot: retry master
2024-02-16 12:25:56 <cely> algitbot: retry master
2024-02-16 12:57:00 <cely> algitbot: retry master
2024-02-16 13:19:47 <cely> algitbot: retry master
2024-02-16 13:41:16 <cely> algitbot: retry master
2024-02-16 13:43:06 <cely> algitbot: retry master
2024-02-16 13:46:38 <cely> algitbot: retry master
2024-02-16 13:49:33 <cely> algitbot: retry master
2024-02-16 13:58:25 <cely> algitbot: retry master
2024-02-16 14:05:38 <cely> algitbot: retry master
2024-02-16 14:08:48 <cely> algitbot: retry master
2024-02-16 14:13:56 <cely> algitbot: retry master
2024-02-17 00:30:37 <omni> I've been away longer than I thought I'd be
2024-02-17 00:36:54 <omni> perhaps we should x86* this? https://git.alpinelinux.org/aports/tree/community/py3-sqlalchemy/APKBUILD#n38
2024-02-17 00:37:24 <omni> maybe not the same thing happening
2024-02-17 00:37:52 <omni> algitbot: retry master
2024-02-17 00:38:05 <omni> algitbot: retry 3.19-stable
2024-02-17 02:11:57 <celie> algitbot: retry master
2024-02-17 02:13:18 <celie> algitbot: retry master
2024-02-17 02:19:30 <celie> algitbot: retry master
2024-02-17 02:27:16 <celie> algitbot: retry master
2024-02-17 03:01:36 <cely> algitbot: retry master
2024-02-17 03:04:31 <cely> algitbot: retry master
2024-02-17 03:15:11 <cely> algitbot: retry master
2024-02-17 03:31:05 <cely> algitbot: retry master
2024-02-17 03:58:51 <cely> algitbot: retry master
2024-02-17 04:19:04 <cely> algitbot: retry master
2024-02-17 04:32:20 <cely> algitbot: retry master
2024-02-17 04:51:55 <cely> algitbot: retry master
2024-02-17 04:59:23 <cely> algitbot: retry master
2024-02-17 05:06:44 <cely> algitbot: retry master
2024-02-17 05:13:10 <cely> algitbot: retry master
2024-02-17 05:37:31 <cely> algitbot: retry master
2024-02-17 06:04:09 <cely> algitbot: retry master
2024-02-17 06:21:04 <cely> algitbot: retry master
2024-02-17 06:31:59 <cely> algitbot: retry master
2024-02-17 06:36:10 <cely> algitbot: retry master
2024-02-17 06:37:27 <cely> algitbot: retry master
2024-02-17 06:45:49 <cely> algitbot: retry master
2024-02-17 06:52:44 <cely> algitbot: retry master
2024-02-17 06:54:05 <cely> algitbot: retry master
2024-02-17 06:57:24 <cely> algitbot: retry master
2024-02-17 06:59:20 <cely> algitbot: retry master
2024-02-17 07:10:59 <cely> algitbot: retry master
2024-02-17 12:09:18 <omni> oh-no
2024-02-17 12:17:53 <omni> hmm... -buildmode=pie requires external (cgo) linking, but cgo is not enabled
2024-02-17 12:18:50 <omni> cely: ping
2024-02-17 12:32:27 <omni> nmeum: ?
2024-02-17 14:22:17 <cely> Hmm, i should know better than to open MR's that compile with one version of the compiler, and then get merged with another
2024-02-17 14:23:57 <cely> So, both minio and minio-client are affected
2024-02-17 14:40:27 <cely> algitbot: retry master
2024-02-17 14:55:06 <cely> I'm not sure whether this should be fixed in the Minio* APKBUILDs, or in the Go compiler itself
2024-02-17 14:55:39 <cely> It seems to be passing with x86_64, aarch64, and ppc64le
2024-02-17 14:55:59 <cely> Fails on x86, 32-bit arm*, and s390x
2024-02-17 14:56:23 <cely> Didn't test riscv64, as that won't have Go 1.22 yet due to community being blocked
2024-02-17 15:00:20 <cely> https://bugs.gentoo.org/924632
2024-02-17 15:01:39 <cely> That mentions this error occurring on x86
2024-02-17 15:03:11 <cely> https://github.com/golang/go/issues/64875 mentions it on riscv64 and s390x
2024-02-17 15:07:25 <cely> https://pkgs.alpinelinux.org/packages?name=minio-client&branch=edge
2024-02-17 15:12:37 <cely> Clicking through each arch and looking at "Depends", it seems it is true, CGO_ENABLED=0 is only respected for x86_64, aarch64, and ppc64le, the rest have a depends on `musl`
2024-02-17 15:25:59 <cely> omni: !61018 should fix the issue
2024-02-17 15:27:10 <cely> This is going to affect a lot of other aports during the Go rebuild
2024-02-17 15:27:40 <omni> uhm, yeah...
2024-02-17 15:28:43 <cely> I wonder if i should go over my aports with CGO_ENABLED=0 and rebuild them with Go 1.22 before-hand
2024-02-17 15:30:20 <omni> rg "CGO_ENABLED=0" | wc -l
2024-02-17 15:30:22 <omni> 73
2024-02-17 15:36:25 <cely> Unfortunately, that's not true
2024-02-17 15:37:04 <cely> Some Go aports do not call `go build` directly, but use the Makefile upstream provides
2024-02-17 15:37:18 <cely> and upstream sets CGO_ENABLED=0 in that Makefile
2024-02-17 15:37:56 <cely> So, this will affect a lot more than the 73 aports that have CGO_ENABLED=0 in APKBUILD
2024-02-17 15:41:14 <cely> I think i will do a rebuild of elvish, glab, and joker that i maintain now, and will look through the rest of my Go aports later on to find those that use a Makefile with CGO_ENABLED=0
2024-02-17 16:04:32 <cely> !61021
2024-02-17 16:05:43 <cely> My MR to prevent Go aports i maintain from erroring out during the big Go rebuild
2024-02-17 16:07:02 <cely> Will look deeper into other Go aports i maintain to look for CGO_ENABLED=0 in upstream Makefile either tomorrow or next week
2024-02-17 21:36:59 <andypost[m]> algitbot: retry master
2024-02-17 21:41:01 <andypost[m]> algitbot: retry master
2024-02-17 21:58:34 <andypost[m]> algitbot: retry master
2024-02-17 22:45:31 <omni> lol
2024-02-18 10:58:14 <ikke> cely: https://github.com/cli/cli/issues/8668
2024-02-18 11:21:10 <omni> !61044
2024-02-19 03:43:44 <omni> too bad dotnet7 wasn't removed yet #15724
2024-02-19 13:31:26 <omni> is dotnet7-build stuck on aarch64 or just taking a very long time?
2024-02-19 13:31:39 <omni> could it be aborted since it's removed anyway?
2024-02-19 16:10:35 <omni> ikke: is dotnet7-build stuck?
2024-02-19 19:20:03 <ikke> omni: apparently, yes
2024-02-19 19:20:06 <ikke> algitbot: retry master
2024-02-20 01:19:02 <andypost[m]> algitbot: retry master
2024-02-20 02:51:15 <andypost[m]> algitbot: rerty master
2024-02-20 02:51:23 <andypost[m]> algitbot: retry master
2024-02-20 14:14:24 <omni> as suspected
2024-02-20 14:25:20 <omni> ok, it wasn't expected to fail on ppc64le
2024-02-20 14:26:28 <omni> algitbot: retry master
2024-02-21 01:31:05 <omni> algitbot: retry master
2024-02-21 21:27:56 <omni> algitbot: retry master
2024-02-21 21:27:59 <omni> fetch failed
2024-02-22 20:00:01 <omni> algitbot: retry master
2024-02-22 21:11:21 <omni> algitbot: retry master
2024-02-22 23:15:23 <andypost[m]> algitbot: retry master
2024-02-23 00:52:54 <omni> algitbot: retry master
2024-02-23 00:54:30 <omni> hmm.. I'm slow...
2024-02-23 00:55:09 <omni> ikke: is there any way to prioritize the build of go on riscv64?
2024-02-23 00:55:55 <omni> no, wait, its already built
2024-02-23 00:56:08 <omni> just not uploaded yet, but can be used by the builder
2024-02-23 01:43:41 <omni> algitbot: retry master
2024-02-23 02:15:35 <omni> I saw no objections
2024-02-23 03:27:37 <celie> algitbot: retry master
2024-02-23 21:49:41 <ikke> algitbot: retry master
2024-02-24 03:12:51 <andypost[m]> algitbot: retry master
2024-02-24 08:26:36 <ikke> algitbot: retry master
2024-02-24 12:09:42 <omni> algitbot: retry master
2024-02-24 12:50:39 <omni> algitbot: retry master
2024-02-24 12:55:13 <omni> algitbot: retry master
2024-02-24 12:56:39 <omni> rclone and hare, sitting in a tree, f a i l i n g
2024-02-24 13:01:22 <ikke> ahuh
2024-02-24 13:01:55 <ikke> ah, didn't get that libjxl was fixed
2024-02-24 13:05:29 <omni> yeah, ptrc fixed it with !61170
2024-02-24 13:05:44 <ikke> saw the commit in the channel log
2024-02-24 13:13:45 <celie> algitbot: retry master
2024-02-24 13:30:31 <celie> algitbot: retry master
2024-02-24 13:31:41 <celie> algitbot: retry master
2024-02-24 13:32:54 <celie> algitbot: retry master
2024-02-24 13:49:43 <omni> oh-no
2024-02-24 13:49:57 <omni> ffs, I didn't look at the added commit
2024-02-24 13:49:58 <omni> ffs
2024-02-24 13:50:03 <omni> I already said that
2024-02-24 13:50:07 <omni> *sigh*
2024-02-24 13:54:20 <celie> We need a bot that checks for un-squashed commits
2024-02-24 14:07:03 <omni> shouldn't some be possible to do with git-hooks?
2024-02-24 14:07:55 <celie> Probably
2024-02-24 14:08:17 <omni> that could get rid of some of those, if only commit messages that started with something in the root dir were allowed
2024-02-24 14:20:10 <omni> I saw
2024-02-24 14:20:12 <omni> # Maximal allowed size (in bytes) of a file.
2024-02-24 14:20:13 <omni> FILE_SIZE_LIMIT=262144  # 256 kiB
2024-02-24 14:20:47 <omni> but I think I managed to commit something way bigger recently, som 40MiB log file or what was it
2024-02-24 14:36:22 <omni> #15812
2024-02-24 14:37:38 <ikke> Not every commit affects aports though
2024-02-24 14:38:24 <ikke> so we cannot force things to start with (main/community/testing)/
2024-02-24 14:45:08 <omni> what other than that and the files in the root dir should a commit message be able to begin with?
2024-02-24 14:45:24 <ikke> new files that are added to the rootdir
2024-02-24 14:47:43 <ikke> We could check for '^[a-z]+:'
2024-02-24 14:48:10 <ikke> We could check for '^[a-z]\S+:'
2024-02-24 14:53:34 <omni> when new files are added to the rootdir the hook could be updated to allow for them in the commit message
2024-02-24 14:53:39 <omni> git log --oneline | grep -Ev "main|community|testing|scripts|README|COMMITSTYLE|====="
2024-02-24 14:53:43 <ikke> nah
2024-02-24 14:53:46 <ikke> way too rigid
2024-02-24 14:53:58 <omni> I mostly see "*/*:" and errouneous
2024-02-24 14:54:21 <ikke> try git log --oneline .editorconfig .gitattributes .githooks .gitlab .gitignore .gitlab-ci.yml .mailmap
2024-02-24 14:56:05 <omni> so a bunch of reasonable things could be added to my list of things above, sure
2024-02-24 14:56:52 <ikke> Or we just check that it follows a general style and don't enfore the exact words
2024-02-24 14:57:29 <ikke> One tricky thing is when you push new branches
2024-02-24 14:57:38 <ikke> You don't get a previous hash, so what commits do you check
2024-02-24 14:57:50 <ikke> if you check all history, you will run into commits not according to style
2024-02-24 14:58:48 <omni> I didn't mean to suggest that all history should be checked, the above was just to show what could be acceptable commit messages and not
2024-02-24 14:58:58 <omni> I only want to limit new commits
2024-02-24 14:59:37 <omni> or do you mean that a hook would check all history when a new branch is created?
2024-02-24 14:59:53 <ikke> You don't know what commits are new and what are old
2024-02-24 15:00:30 <ikke> "When creating a new ref, <old-value> is the all-zeroes object name."
2024-02-24 15:06:09 <omni> could the hook be skipped when branching?
2024-02-24 15:07:17 <ikke> the hook itself could detect it and allow new branches
2024-02-24 15:07:24 <ikke> I mentioned that in the issue
2024-02-24 15:13:14 <omni> thanks
2024-02-24 22:00:00 <ptrc> whoops, wrong repo
2024-02-24 22:00:06 <ptrc> eh, whatever
2024-02-24 22:09:18 <ikke> want me to delete the ref?
2024-02-24 22:10:52 <ptrc> nah, i opened a MR from it
2024-02-24 22:11:02 <ptrc> i'll just merge that, and it's gonna get deleted anyway :p
2024-02-24 22:30:13 <ikke> ptrc: fine
2024-02-25 02:16:26 <celie> algitbot: retry master
2024-02-25 02:18:10 <celie> algitbot: retry master
2024-02-25 02:19:22 <celie> algitbot: retry master
2024-02-25 02:20:45 <celie> algitbot: retry master
2024-02-25 02:22:25 <celie> buildah seems to be failing with on ppc64le with a similar error to github-cli that was fixed in the second commit of !61044
2024-02-25 02:22:51 <celie> that commit added a conditional `CGO_ENABLED=0` for ppc64le
2024-02-25 02:34:38 <celie> algitbot: retry master
2024-02-25 02:36:15 <celie> algitbot: retry master
2024-02-25 02:36:53 <celie> Uh oh, now riscv64 is building buildah as well
2024-02-25 02:38:22 <celie> I wonder if it will finish building, github-cli did, but that failure was had the failure in check()
2024-02-25 02:38:35 <celie> s/was//
2024-02-25 02:38:49 <celie> s/failure//
2024-02-25 02:38:51 <celie> Whatever
2024-02-25 02:46:04 <celie> Hmm, buildah built on riscv64
2024-02-25 02:50:09 <celie> algitbot: retry master
2024-02-25 02:51:25 <celie> algitbot: retry master
2024-02-25 02:52:42 <celie> algitbot: retry master
2024-02-25 02:53:56 <celie> algitbot: retry master
2024-02-25 02:55:08 <celie> algitbot: retry master
2024-02-25 02:56:18 <celie> algitbot: retry master
2024-02-25 02:57:34 <celie> algitbot: retry master
2024-02-25 02:58:49 <celie> algitbot: retry master
2024-02-25 11:43:49 <omni> should we disable buildah on ppc64le for now?
2024-02-25 11:44:19 <ikke> fine with me
2024-02-25 12:10:12 <ikke> sorry for the spam :/
2024-02-25 12:16:30 <ikke> algitbot: retry master
2024-02-25 14:17:58 <celie> !61274 buildah builds its own ginkgo and that is what is failing on ppc64le, splitting up `make` into `make buildah` and `make -C docs` seems to fix that
2024-02-25 14:19:07 <celie> fix that, meaning stop buildah from building its own ginkgo (and go-md2man, and golangci-lint)
2024-02-25 14:19:54 <celie> We have all 3 of that in repo iirc, so no need for buildah to build its own copies
2024-02-25 14:20:22 <celie> but it seems only go-md2man is actually needed to build the man pages
2024-02-25 14:40:53 <celie> Btw, i think the other warning quoted in !61626 is related to !55694, maybe it will need fixing, but i will let someone else look at that
2024-02-25 14:41:27 <celie> Sorry, !61262
2024-02-25 14:42:05 <celie> and !55694
2024-02-25 14:56:55 <celie> Adding `#include <libgen.h>` solves that, so i've included it in !61274
2024-02-25 16:08:02 <ikke> algitbot: retry master
2024-02-25 16:57:14 <ikke> algitbot: retry master
2024-02-25 17:13:25 <ikke> algitbot: retry master
2024-02-25 17:26:44 <ikke> algitbot: retry master
2024-02-25 18:05:20 <ikke> algitbot: retry master
2024-02-25 18:12:22 <ikke> algitbot: retry master
2024-02-25 19:54:22 <ikke> anoying that that zsh test is flaky
2024-02-25 23:13:35 <andypost[m]> algitbot: retry master
2024-02-26 02:42:22 <celie> So, opentofu as the same "failed to find text symbol HI120 relocation" issue also seen in grype, rclone, and rqlite
2024-02-26 02:43:05 <celie> on riscv64, that is
2024-02-26 02:43:52 <celie> s/as/has/
2024-02-26 02:46:34 <celie> I wonder if Go 1.21 should temporarily be added to riscv64 again under a different name to allow those aports to build
2024-02-26 02:46:46 <celie> algitbot: retry master
2024-02-26 02:51:19 <celie> algitbot: retry master
2024-02-26 02:55:38 <celie> algitbot: retry master
2024-02-26 03:06:42 <celie> algitbot: retry master
2024-02-26 03:07:58 <celie> algitbot: retry master
2024-02-26 03:11:19 <celie> algitbot: retry master
2024-02-26 03:22:43 <celie> algitbot: retry master
2024-02-26 03:24:00 <celie> algitbot: retry master
2024-02-26 03:25:12 <celie> algitbot: retry master
2024-02-26 03:26:22 <celie> algitbot: retry master
2024-02-26 15:20:59 <ncopa> algitbot: retry master
2024-02-26 19:07:07 <ikke> lol
2024-02-26 22:24:55 <ptrc> uh oh
2024-02-26 22:25:23 <ptrc> sigh
2024-02-26 22:25:40 <ptrc> why do they error on "unsupported configuration" instead of just disabling the feature
2024-02-26 22:35:13 <ptrc> it's just x86 and ppc64le though...???
2024-02-27 02:42:57 <omni> ptrc: the same architectures that are in disable-moz-stackwalk.patch (that was not removed, btw, just disabled)
2024-02-27 02:43:42 <ptrc> ohh, i must be blind then
2024-02-27 02:43:57 <ptrc> also yeah i messed up a bit 
2024-02-27 02:44:13 <ptrc> weh, i'll fix that up tomorrow-ish
2024-02-27 02:45:12 <omni> so the patch is needed after all?
2024-02-27 20:51:03 <andypost[m]> algitbot: retry master
2024-02-27 20:58:44 <ptrc> algitbot: kick
2024-02-27 20:58:46 <ptrc> a
2024-02-27 21:17:15 <ptrc> algitbot: retry master
2024-02-27 21:53:25 <ptrc> algitbot: retry master 
2024-02-28 00:14:07 <celie> algitbot: retry master
2024-02-28 00:17:21 <celie> algitbot: retry master
2024-02-28 00:20:36 <celie> algitbot: retry master
2024-02-28 00:23:09 <celie> algitbot: retry master
2024-02-28 00:25:33 <celie> algitbot: retry master
2024-02-28 00:28:18 <celie> algitbot: retry master
2024-02-28 00:31:14 <celie> algitbot: retry master
2024-02-28 13:34:52 <celie> algitbot: retry master
2024-02-28 18:54:21 <andypost[m]> algitbot: retry master
2024-02-28 19:46:09 <ikke> algitbot: retry master
2024-02-28 19:56:22 <andypost[m]> ikke: thank you, looks unit-python on arm  is broken 
2024-02-29 12:17:42 <andypost[m]> algitbot: retry master