2024-02-01 00:03:29 algitbot: retry master 2024-02-01 00:30:08 algitbot: retry master 2024-02-01 00:33:35 algitbot: retry master 2024-02-01 00:47:58 algitbot: retry master 2024-02-01 00:55:12 algitbot: retry master 2024-02-01 23:01:32 algitbot: retry 3.19-stable 2024-02-02 16:17:25 cely: that's toxic 2024-02-03 16:47:46 algitbot: retry master 2024-02-03 17:10:03 algitbot: retry master 2024-02-04 11:47:22 Ariadne: from config.log: https://tpaste.us/qE84 2024-02-04 11:47:54 i have fixed it 2024-02-04 11:49:23 ACTION mutters things about '#!/usr/bin/sh' 2024-02-04 11:49:48 algitbot: retry master 2024-02-04 12:52:33 algitbot: retry master 2024-02-04 18:36:02 algitbot: retry master 2024-02-04 18:37:55 algitbot: retry 3.19-stable 2024-02-04 18:37:58 algitbot: retry 3.18-stable 2024-02-04 18:38:01 algitbot: retry 3.17-stable 2024-02-04 18:38:04 algitbot: retry 3.16-stable 2024-02-05 03:12:36 algitbot: retry master 2024-02-05 05:34:31 algitbot: retry master 2024-02-05 11:18:35 "add support for --quiet to only print pkgname" \o/ 2024-02-05 11:45:27 Non-zero exit status: 255 2024-02-05 11:45:29 Parse errors: No plan found in TAP output 2024-02-05 11:45:32 celie: ^ 2024-02-05 11:52:28 ikke: i'm sorry, i don't know what's causing that 2024-02-05 11:52:34 it passed in the CI 2024-02-05 11:53:18 yeah, puzzled as well 2024-02-05 11:54:51 algitbot: retry master 2024-02-05 12:02:04 I wonder if `make -j1 test` will solve it 2024-02-05 13:16:50 but it's before that , right? 2024-02-05 13:17:17 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 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 on armv7: 2024-02-05 13:18:43 t/01-repo.t ................. ok 2024-02-05 13:48:21 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 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 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 sorry for stalling but I'd like to get it sorted 2024-02-05 14:41:46 omni: if you want, you can try `make -j1 tests` to see if it fixes the other errors 2024-02-05 14:43:15 yeah, I'll do that 2024-02-05 14:43:48 Thanks 2024-02-05 14:44:31 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 or well, mostly the first two 2024-02-05 14:52:22 ptrc: in !60270 ? 2024-02-05 14:52:47 i mean, the tests pass on CI anyway, don't they? 2024-02-05 14:55:06 hopefully -j1 solves the test_repo issue, and the environment variables solve the .gitconfig issue 2024-02-05 14:56:00 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 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 celie: ah, tests aren't run on the riscv64 package builder, right? 2024-02-05 15:04:18 Yes 2024-02-05 15:06:25 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 ok, that wasn't it 2024-02-05 15:07:54 Hmm, ok, so maybe try the 2 environment variables then 2024-02-05 15:08:34 just in check() or earlier and outside? 2024-02-05 15:09:07 i think just in check() would be good enough 2024-02-05 15:09:49 yeah, just in check would be enough 2024-02-05 15:13:16 like so? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/60274/diffs 2024-02-05 15:14:20 Yes, but you'll probably have to quote "$builddir" 2024-02-05 15:15:04 Ah, now tests are failing in CI too 2024-02-05 15:15:20 progress 2024-02-05 15:15:35 Maybe you need to mkdir "$builddir"/home 2024-02-05 15:17:10 but "failed to create locked file" rather than "failed to rename lockfile to"... 2024-02-05 15:18:13 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 why "/home" though? 2024-02-05 15:18:26 yeah... 2024-02-05 15:21:31 uhm, other error 2024-02-05 15:21:49 Did it just fix the tests but break abuild 2024-02-05 15:22:43 not sure if it fixed the tests as they only fail on those three package builders, but yeah 2024-02-05 15:23:20 Maybe try `make HOME="$srcdir"` test or `HOME="$srcdir" make test` 2024-02-05 15:23:33 `make HOME="$srcdir" test` 2024-02-05 15:23:48 * 2024-02-05 15:32:07 should I just pass both variables on the make test line? 2024-02-05 15:33:32 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 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 :) 2024-02-05 15:33:48 ok, let's do that first then 2024-02-05 15:37:55 It worked 2024-02-05 15:37:58 Thanks a lot :) 2024-02-05 15:39:49 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 \o/ 2024-02-05 15:52:26 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 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 ikke: I have this idea that you know the most about how the builders are set up 2024-02-05 16:06:56 there is no special rights on ~/.gitconfig, but build systems also have no business in modifying it 2024-02-05 21:55:08 oh oh 2024-02-05 21:55:21 algitbot: retry master 2024-02-05 22:10:21 algitbot: retry master 2024-02-05 23:04:26 algitbot: retry master 2024-02-05 23:04:29 please work 2024-02-05 23:04:58 aw 2024-02-05 23:16:36 ptrc: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/59838#note_375289 2024-02-05 23:18:15 ooh, okay 2024-02-06 09:37:18 Hmm, apparently the ARM builders are faster than the CI runners 2024-02-06 09:59:44 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 That would probably mean it would need yet another rebuild to get the patch into library/* 2024-02-06 10:00:30 or rather, get the patch out of library/* 2024-02-06 10:00:31 hehe 2024-02-06 10:06:42 i think LLVM 17 is faster, so hopefully that's reflected in the rebuilds too 2024-02-06 10:10:12 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 I need to catch up... 2024-02-06 11:01:54 i think it's mostly confirmed, half a patch works 2024-02-06 11:02:13 and all the archs besides riscv64 have Rust 1.73.0 2024-02-06 11:03:06 so llvm17 didn't work to build 1.73.0? 2024-02-06 11:03:24 No, LLVM 17 will work 2024-02-06 11:03:36 but llvm16 was used 2024-02-06 11:03:52 Yes, that's why we have !60295 2024-02-06 11:04:39 and i've tried it out, just remove the patch for compiler/* and keep library/* patched 2024-02-06 11:04:47 and the CI should succeed 2024-02-06 11:05:26 After that we either rebuild again the the patch completely removed, or try our luck with 1.74 2024-02-06 11:05:30 ok 2024-02-06 11:05:35 s/the// 2024-02-06 11:05:44 with the* 2024-02-06 11:06:36 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 This time it is probably necessary 2024-02-06 11:06:51 until the last couple of upgrades 2024-02-06 11:07:23 to make it clear that we want 1.73 to build 1.73 2024-02-06 11:08:08 (Of course, 1.72 has probably been removed from the apk index, but still, better to be safe) 2024-02-06 11:12:15 ah, so _bootver=1.73.0 even? 2024-02-06 11:12:49 it's used in $makedepends_build 2024-02-06 11:13:00 cargo-bootstrap=>$_bootver 2024-02-06 11:13:02 rust-bootstrap>=$_bootver 2024-02-06 11:13:21 why do they differ? => vs >= 2024-02-06 11:13:42 Ah 2024-02-06 11:13:52 You caught a typo :) 2024-02-06 11:14:40 right? 2024-02-06 11:15:07 >= is the right one 2024-02-06 11:15:13 thought so 2024-02-06 11:28:34 cely: CI for ARM runs in qemu 2024-02-06 11:33:05 Oh ok 2024-02-06 11:33:22 Thanks for telling me, didn't know that 2024-02-06 11:40:54 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 i kind of want to minimize any aport potentially getting built with that patch in effect.. 2024-02-06 11:42:39 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 one of my own updating the patch? 2024-02-06 11:49:54 add a commit from you to the MR doing that? 2024-02-06 11:50:33 i mean, updating the patch to remove the patched files under compiler/* 2024-02-06 11:50:35 ah, I thought that was implied =) 2024-02-06 11:53:01 ptrc: did we push at the same time? 2024-02-06 11:53:05 sorry about that 2024-02-06 11:54:46 Whoops, did that confuse Gitlab? 2024-02-06 11:57:59 cely: what? 2024-02-06 11:59:29 Pushing at the same time 2024-02-06 12:22:46 cely: https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1267787 2024-02-06 12:23:11 I retriggered the x86_64 pipeline and it failed 2024-02-06 12:28:14 omni: That's what i've been trying to say, it still needs half a patch :) 2024-02-06 12:28:49 We need to add the intrinsics back to the compiler first while keeping them out of the library 2024-02-06 12:29:19 ah 2024-02-06 12:29:27 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 maybe I should make some coffee... 2024-02-06 12:36:40 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 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 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 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 ๐Ÿ‘ 2024-02-06 13:19:29 maybe I should have a look at our other patches 2024-02-06 13:25:20 i'm actually looking into that now, there's quite a bit of renaming in 1.75.0 2024-02-06 13:32:37 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 so optimistically rm'ing it, and let's see what the CI thinks of that later 2024-02-06 13:34:40 I'm getting distraced by other things meanwhile 2024-02-06 13:34:52 perhaps I should follow and review what you do instead 2024-02-06 13:36:14 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 alice suggested to continue "completely without the patch, then 1.74" 2024-02-06 13:42:42 i'll have a look at the Gitlab comment 2024-02-06 14:05:02 i got Rust 1.74 to build with Rust 1.73 half unpatched 2024-02-06 14:06:39 omni: btw, i used the rust1730, rust1740 method you used in your previous MR 2024-02-06 14:09:35 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 and on armv7: https://gitlab.alpinelinux.org/Celeste/aports/-/jobs/1267893 2024-02-06 14:11:44 well, to say that I used the method would be an overstatement, I think I never succeeded 2024-02-06 14:12:30 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 and now for the grand finale of this building that: https://gitlab.alpinelinux.org/Celeste/aports/-/jobs/1267943 2024-02-06 14:14:38 I saw an error: >>> ERROR: rust-aux*: libscudo.so: path not found 2024-02-06 14:14:42 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 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 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 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 At least on x86_64 2024-02-06 14:18:23 hehe 2024-02-06 14:20:19 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 ok, but should I go ahead and merge 60301 then? 2024-02-06 14:21:06 Of course! 2024-02-06 14:21:42 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 sorry for stalling then =) 2024-02-06 14:22:09 I guess I also wanted it to succeed on arm* 2024-02-06 14:25:47 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 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 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 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 The rest is just taking into consideration `target_os = "hurd"` in lfs64-rust.patch 2024-02-06 14:46:51 and it seems Rust 1.75.0 has panicked 2024-02-06 14:53:19 Hmm, the file isn't in 1.74, so probably reorganized from somewhere else 2024-02-06 15:07:37 Seems we've hit this issue: https://github.com/rust-lang/rust/issues/117885 2024-02-06 15:08:40 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 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 also saw https://releases.rs/docs/1.74.1/ 2024-02-06 15:16:01 haven't really looked at it but would that be something in between instead of 1.74.0? 2024-02-06 15:17:05 Hmm 2024-02-06 15:17:06 Might be workable 2024-02-06 15:17:40 So, i guess your MR could be for 1.74.1 instead 2024-02-06 15:18:49 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 Hehe !60307 failed on the 2 architectures that haven't been uploaded yet 2024-02-06 15:22:14 Ah now x86 can be retried :) 2024-02-06 15:24:22 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 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 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 i wonder what errors i'll see if i try building 1.75 with 1.73 2024-02-06 16:19:26 Haha 2024-02-06 16:19:50 "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 So, it does a check to make sure you follow the rules 2024-02-06 16:22:21 I'm sure that can be patched :D 2024-02-06 16:28:36 Now i'll be trying to build 1.75.0 with your 1.74.1 2024-02-06 16:31:41 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 rebased on your 1.74.1 branch 2024-02-06 16:32:27 so hopefully it is easier to extract the commit with the patch modifications (of which there are many) 2024-02-06 16:32:57 Lots of reorganizations, also lots of things upstreamed 2024-02-06 16:33:36 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 as we pass `--set="rust.remap-debuginfo=true"` to ./configure 2024-02-06 16:34:56 in your -again branch you mean? 2024-02-06 16:35:34 Yes 2024-02-06 16:35:43 let's merge !60307 once riscv64 is done with 1.73.0-r1, right? 2024-02-06 16:36:00 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 Yes, sure 2024-02-06 16:36:23 Might not even need to wait for that, hehe 2024-02-06 16:38:07 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 yes 2024-02-06 16:39:33 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 What patches are you thinking about? 2024-02-06 16:40:10 dua-cli had a patch, but that's been upstreamed 2024-02-06 16:40:25 I just thought there were several 2024-02-06 16:40:34 perhaps not 2024-02-06 16:40:47 Might be, but i can't think of anything off the top of my head 2024-02-06 16:40:57 and yes 1.74.x will enable quite a few aports 2024-02-06 16:41:06 me neither but I couldn't even think of dua-cli 2024-02-06 16:41:17 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 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 Sure, sounds good 2024-02-06 16:41:55 i'll also go AFK soon 2024-02-06 16:42:05 but will probably wait to see the results of my 1.75 CI 2024-02-06 16:42:32 Thankfully LLVM 17 seems to have given Rust a speed boost 2024-02-06 16:42:41 and probably also the newer Rust versions :) 2024-02-06 17:02:06 speed boosts are always appreciated 2024-02-06 17:03:03 :) 2024-02-06 17:15:31 https://gitlab.alpinelinux.org/Celeste/aports/-/jobs/1268106 2024-02-06 17:15:45 So, 1.75.0 built fine, but failed tests 2024-02-06 17:16:31 Searching for the error message brought me to: https://github.com/rust-lang/rust/issues/119571 2024-02-06 17:16:55 which is an open issue 2024-02-06 17:18:00 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 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 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 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 They're disabled on 32-bit arm and riscv64 though 2024-02-06 17:33:11 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 yeah, I'll open a 1.75.0 MR 2024-02-06 17:47:56 riscv64 is sure taking its time 2024-02-06 18:26:28 there, let's see.. 2024-02-06 22:00:39 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 oh no... 2024-02-06 22:30:13 algitbot: retry master 2024-02-06 22:42:33 uh.. built fine with rust 1.73.0-r1 2024-02-06 23:24:29 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 omni: if it was one that i rebased, feel free to cancel it 2024-02-06 23:38:42 I don't see any running that you rebased 2024-02-06 23:38:52 but I'll let them be 2024-02-06 23:41:48 one thing I'd like to see now is if arti will fail on other architectures too 2024-02-06 23:41:51 probably 2024-02-06 23:43:21 and x86* just started building rust-1.74.1-r0, the others are done 2024-02-06 23:44:37 "An error occurred while making the request." while trying to re-trigger the pipeline for ppc64le in 60315 2024-02-06 23:44:45 !60315 2024-02-06 23:45:40 there is something with the UI today... 2024-02-07 00:18:33 ok 2024-02-07 00:37:14 So, Arti doesn't build with new Rust? 2024-02-07 00:38:12 Anyway, regarding the Gitlab UI, i've also noticed something a bit off 2024-02-07 00:38:45 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 I think there was something similar once before with the tor aport 2024-02-07 00:40:11 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 but more importantly, rust 1.75.0 tests are failing for at least aarch64 and armhf 2024-02-07 00:40:46 riscv64 currently running and others I don't know 2024-02-07 00:44:19 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 Rust stable, i mean 2024-02-07 00:48:42 I just saw something... 2024-02-07 00:48:50 What is it? 2024-02-07 00:50:30 https://github.com/rust-lang/rust/pull/40113 mentioned in musl-fix-linux_musl_base.patch 2024-02-07 00:50:45 perhaps try without that patch? 2024-02-07 00:53:18 Hmm, i'm not so sure, is the CI still being slow? 2024-02-07 00:54:48 I'm not sure either 2024-02-07 00:55:26 oh, time for chromium upgrades :D 2024-02-07 00:57:25 Also, i just noticed https://github.com/msrd0/docker-abuild-arm/tree/main/rust 2024-02-07 00:57:50 That's on 1.75.0 2024-02-07 00:58:12 Maybe you could see if there's anything different in the patches there 2024-02-07 00:58:49 and I saw that voidlinux is at rust 1.75.0 too 2024-02-07 00:59:04 Hehe, it contains !check in options 2024-02-07 00:59:09 so probably won't help us out there 2024-02-07 00:59:20 https://github.com/void-linux/void-packages/tree/master/srcpkgs/rust 2024-02-07 00:59:36 but at least we can compare the patches 2024-02-07 00:59:40 yeah 2024-02-07 01:02:13 I think I need a break 2024-02-07 01:02:16 Even OpenBSD is at Rust 1.75.0 ;) 2024-02-07 01:02:25 :D 2024-02-07 01:03:01 there, just x86 left to be done with 1.74.1-r0 2024-02-07 01:03:08 :) 2024-02-07 01:06:42 \o/ 2024-02-07 01:09:35 I'm just about to have a go at the test issue 2024-02-07 01:09:47 but don't know if the CI is still overloaded 2024-02-07 01:10:55 well... !60328 & !60333 :D 2024-02-07 01:14:36 cely: I say try, just use patience 2024-02-07 01:15:19 algitbot: retry master 2024-02-07 01:17:42 Oh, i don't want to be competing with Chromeium 2024-02-07 01:22:11 I don't think we should allow Rust 1.75.0 to be blocked again 2024-02-07 01:22:32 what do you mean? 2024-02-07 01:22:49 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 aha 2024-02-07 01:23:52 as they aren't even upstream's tests anyway 2024-02-07 01:25:05 I haven't really dug into the tests 2024-02-07 01:32:01 Hmm, i see the APKBUILD has something for rust-analyzer 2024-02-07 01:32:15 i mean, it enables something for the archs rust-analyzer is enabled for 2024-02-07 01:36:44 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 However, i think logically, vendor checksums would only need to be cleared if we were patching something 2024-02-07 01:39:20 and in Rust 1.75.0 we don't patch anything with the .patch.noauto files 2024-02-07 01:39:45 So, maybe the whole `prepare()` can be removed 2024-02-07 01:42:21 algitbot: retry master 2024-02-07 01:44:42 Hmm, libei seems to build fine now 2024-02-07 01:45:01 or rather, test fine 2024-02-07 01:53:39 cely: well, I did that, didn't I? 2024-02-07 01:54:04 perhaps you just continued from your fork, I did some additional changes 2024-02-07 01:56:26 Oh, sorry, i probably should go see what changes you made 2024-02-07 01:57:16 yes, maybe I did something on my own that made everything fail =) 2024-02-07 01:58:10 Nah, the test failure was already there when i tried it in my fork 2024-02-07 01:59:35 ok 2024-02-07 01:59:56 something something "rpath" and we patch some things "rpath" 2024-02-07 02:01:16 // XXX: hacky hacky 2024-02-07 02:01:38 ACTION waits for the rest of the paste 2024-02-07 02:02:53 nah, that's it 2024-02-07 02:03:05 main/rust/need-rpath.patch 2024-02-07 02:03:21 the important part at least 2024-02-07 02:03:57 comments are the most important part of code 2024-02-07 02:04:13 and programming is about removing code, right? 2024-02-07 02:10:49 Not really sure i'm getting your point 2024-02-07 02:11:21 no, I'm just being silly 2024-02-07 02:11:46 but I'm looking at main/rust/need-rpath.patch 2024-02-07 02:11:57 That's good, thanks :) 2024-02-07 02:12:17 because it is patching compiler/rustc_codegen_ssa/src/back/link.rs 2024-02-07 02:12:56 and the test was failing somewhere around there 2024-02-07 02:13:07 I may or may not be onto something 2024-02-07 02:14:51 However, msrd0/docker-abuild-arm still applies that 2024-02-07 02:20:34 mm... 2024-02-07 02:21:02 yeah, I should probably have a look at theirs and the void patches 2024-02-07 02:24:26 Probably want to see if there's anything they've stopped applying 2024-02-07 02:27:01 Hmm, it really is bad 2024-02-07 02:27:04 Rust can't compile anything 2024-02-07 02:29:07 I think our test is failing at https://github.com/rust-lang/rust/commit/5aeb6a326f2fa941061b60c9286665847fe0401e#diff-4622a614fea8371c5c7b44c71f9c4959f377fa0e08dce6fd9a9cfde7dd4d7477R88 2024-02-07 02:29:44 called `Result::unwrap()` on an `Err` value: Error { kind: InvalidInput, message: "cannot make an empty path absolute" } 2024-02-07 02:29:58 is the line from our test 2024-02-07 02:30:19 uhm meant to paste this line: 2024-02-07 02:30:20 thread 'rustc' panicked at compiler/rustc_codegen_ssa/src/back/rpath.rs:88:43: 2024-02-07 02:30:57 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 i was just looking at that too :) 2024-02-07 02:40:14 Aha! 2024-02-07 02:40:32 i just got `rustc` to compile something 2024-02-07 02:40:43 it turns out you not only need -o 2024-02-07 02:41:40 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 So, if i modify all the `_rustc` calls in `check-rustc` to include `-o ./` they pass 2024-02-07 02:46:50 The ones with +crt-static don't need and still pass that though 2024-02-07 02:46:57 don't need that* 2024-02-07 02:48:26 hmm.. ok 2024-02-07 02:49:00 I just saw in our APKBUILD: 2024-02-07 02:49:02 # This is related to change-rpath-to-rustlib.patch. 2024-02-07 02:49:17 but don't see no change-rpath-to-rustlib.patch 2024-02-07 02:49:36 I think it is unrelated to our current issue, but still 2024-02-07 02:50:04 there is some cleanup that we might as well do now 2024-02-07 02:50:20 After seeing that need-rpath.patch is equivalent to always having `-Crpath` set 2024-02-07 02:50:45 and looking at the commit you mentioned 2024-02-07 02:51:01 i am more certain this issue is related to https://github.com/rust-lang/rust/issues/119571 2024-02-07 02:51:22 It is still an open issue, and i don't see any pull requests linked to it 2024-02-07 02:55:23 i wonder if we should just revert that commit 2024-02-07 02:59:05 the whole https://github.com/rust-lang/rust/pull/116487 ? 2024-02-07 02:59:37 or just https://github.com/rust-lang/rust/pull/116487/commits/5aeb6a326f2fa941061b60c9286665847fe0401e ? 2024-02-07 03:04:12 Probably try with just the commit first 2024-02-07 03:04:31 i wonder if cargo ever calls rustc without a proper -o 2024-02-07 03:05:14 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 We only have this because `check-rustc` calls rustc directly 2024-02-07 03:07:05 and looking at need-rpath.patch now 2024-02-07 03:07:20 if we set RUSTC_BOOTSTRAP when running `check-rustc` it works too 2024-02-07 03:09:22 I was almost about to push with that commit reverted 2024-02-07 03:11:18 well, I will 2024-02-07 03:11:59 this is a potentially breaking change for some rust users, isn't it? 2024-02-07 03:13:52 You mean reverting the commit or not reverting it? 2024-02-07 03:14:25 If you mean not reverting it, as i was saying, i think most users use rust through cargo 2024-02-07 03:14:34 and don't call rustc directly 2024-02-07 03:16:22 I mean not reverting "rustc_codegen_ssa: use try_canonicalize in rpath" 2024-02-07 03:16:28 would be breaking for some 2024-02-07 03:16:53 by upgrading to 1.75.0 2024-02-07 03:17:49 i've just tried it 2024-02-07 03:17:53 cargo compiles things fine 2024-02-07 03:18:01 so, only users that call rustc directly would be affected 2024-02-07 03:18:13 (like the `check-rustc` script we run in `check()`) 2024-02-07 03:18:32 So, i'm not sure about breaking 2024-02-07 03:19:31 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 some users may be calling rustc directly 2024-02-07 03:19:58 Probably 2024-02-07 03:20:06 but my impression is everyone uses cargo now ;p 2024-02-07 03:20:44 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 Anyway, either reverting it or setting RUSTC_BOOTSTRAP is fine with me 2024-02-07 03:21:33 So, i will go with what you decide 2024-02-07 03:21:59 and if the decision affects some other thing in an unexpected way, other users will let us know :) 2024-02-07 03:23:36 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 it's upstream's change + our patch to always enable `-Crpath` 2024-02-07 03:24:53 So, maybe reverting that commit is a good idea 2024-02-07 03:25:26 at least, until someone reviews whether need-rpath.patch is still needed 2024-02-07 03:26:45 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 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 I'll add coments and also rename my revert-patch 2024-02-07 03:27:51 https://www.rust-lang.org/learn/get-started 2024-02-07 03:28:17 "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 hah 2024-02-07 03:29:37 well, I read src/doc/rustc/src/what-is-rustc.md 2024-02-07 03:32:39 ah, i looked at the output of `cargo build --verbose` and cargo calls rustc with --out-dir set 2024-02-07 03:32:44 so that also fixes the issue 2024-02-07 03:33:05 https://doc.rust-lang.org/rustc/index.html 2024-02-07 03:33:36 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 yeah, I already pushed with reverting the commit and it's building 2024-02-07 03:34:43 but I'll rename my patch and add some comments 2024-02-07 03:35:04 Let's see if the tests pass first 2024-02-07 03:59:59 cely: x86 succeeded 2024-02-07 04:00:59 That's great :) 2024-02-07 04:01:25 x86_64 also now 2024-02-07 04:08:50 that's enough for me, I'll push the patch name change commit with comments 2024-02-07 04:11:37 so now I'll let them all run, and I've also triggered riscv64 2024-02-07 04:14:00 cely: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/60315/diffs#0de429d99058768d45ad905892a469bf75627150 2024-02-07 04:14:54 gtg, c u l8r 2024-02-07 04:15:00 Bye 2024-02-07 04:15:19 Diff looks good 2024-02-07 04:44:28 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 Oops, armv7 failed tests 2024-02-07 05:13:53 i think that means the "+crt-static still broken" comment is still valid 2024-02-07 05:15:08 Let's see if the tests similarly fails for armhf and riscv64 2024-02-07 05:15:17 Ok, it just failed for armhf 2024-02-07 05:30:00 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 Based on beta9 from 2024-01-28, i think 1.76.0 should be a straight-forward upgrade 2024-02-07 05:57:14 No changes in patches, unless you want to align them again 2024-02-07 05:59:10 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 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 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 Will you be using the solution from !60344? 2024-02-07 12:32:26 cely: no_empty_output_rpath.patch? 2024-02-07 12:32:33 Yes 2024-02-07 12:32:55 instead of reverting the other thing you mean 2024-02-07 12:33:12 Yes 2024-02-07 12:35:06 let's do that, and also disable tests for arm* and riscv64 again 2024-02-07 12:35:59 and, to jinx it, then I think we're ready for 1.75.0! 2024-02-07 12:43:08 i would rather it be patched closer to the source though 2024-02-07 12:43:46 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 so the revert patch may be a better option after all? 2024-02-07 12:53:52 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 being stuck at pre-1.74 was more of a blocker 2024-02-07 12:58:10 Lots of things still depend upon 1.75.0 2024-02-07 12:58:30 which is why you got another MR upgrading it to that 2024-02-07 12:58:44 yes yes.. 2024-02-07 12:58:49 From my own draft MR's, i can think of: hurl, lemmy, pict-rs 2024-02-07 12:59:28 Maybe you can ask Kladky if he knows where the output_directory could be coming from 2024-02-07 12:59:37 or rather, out_directory 2024-02-07 12:59:51 i keep circling back to compiler/rustc_session/src/config.rs 2024-02-07 13:00:07 or could you? =) 2024-02-07 13:00:13 in !60315 then 2024-02-07 13:01:01 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 Maybe i will ask another question instead 2024-02-07 13:08:21 sure 2024-02-07 13:08:22 If no plan to submit it upstream, then maybe we should stick with the original revert 2024-02-07 13:10:40 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 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 omni cat is curious? 2024-02-07 13:19:39 :) 2024-02-07 13:20:05 ๐Ÿ˜ผ 2024-02-07 13:20:38 but I see now that their pipelines ran... 2024-02-07 13:21:04 The results from CI here replicate that from !60344 2024-02-07 13:21:09 hehe 2024-02-07 13:21:51 should replicate* 2024-02-07 13:22:32 they also --set="rust.remap-debuginfo=false" 2024-02-07 13:22:40 ... 2024-02-07 13:23:18 That's what bootstrap-vendor-remap.patch is for 2024-02-07 13:23:40 ah 2024-02-07 13:23:57 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 now x86_64 is done 2024-02-07 13:27:27 :) 2024-02-07 13:28:36 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 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 since 1.76.0 looked like a straight-forward upgrade when i tried it out for x86_64 2024-02-07 13:30:13 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 pushed that 2024-02-07 13:33:33 cely: ok, last chance before I merge what is currently in !60315 2024-02-07 13:34:13 ACTION looks 2024-02-07 13:36:28 Looks good :) 2024-02-07 13:37:19 ok, let's go! 2024-02-07 13:38:00 Thanks 2024-02-07 13:38:22 .. 2024-02-07 13:38:32 wat 2024-02-07 13:38:33 stap! 2024-02-07 13:38:46 Connection timed out :) 2024-02-07 13:39:02 algitbot: retry master 2024-02-07 13:39:04 *phew* 2024-02-07 13:39:42 well.. let's give it a couple of minutes 2024-02-07 13:39:44 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 maybe 2024-02-07 13:41:03 i wonder if we broke a record in the number of downloads 2024-02-07 13:41:09 but isn't also the ppc64le located elsewhere? 2024-02-07 13:41:11 ikke: ? 2024-02-07 13:42:09 It's hosted by OSU 2024-02-07 13:43:44 Hmm, the builders still seem to be using curl for abuild-fetch 2024-02-07 13:43:59 (the CI uses wget now) 2024-02-07 13:44:39 but probably not connected 2024-02-07 13:45:00 and looking at build.a.o, ppc64le seems to have retried rust 2024-02-07 13:46:52 ACTION suspects someone doing things behind the scenes... 2024-02-07 13:47:06 So, what are our plans for 1.76 tomorrow? 2024-02-07 13:47:17 as, in a way, we are when talking here rather than in #alpine-devel 2024-02-07 13:47:37 hehe 2024-02-07 13:47:38 yeah, I was thinking about 1.76 too... 2024-02-07 13:53:52 maybe one could fetch a commit tarball that would be close to what 1.76.0 will be? 2024-02-07 13:56:15 https://static.rust-lang.org/dist/2024-01-28/rustc-beta-src.tar.xz 2024-02-07 13:56:25 1.76.0-beta9 2024-02-07 13:57:06 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 thanks! 2024-02-07 13:57:47 You're welcome 2024-02-07 13:57:53 but not buildable until 1.75.0 hits the builders 2024-02-07 13:58:09 So, probably what you can do for now is align the patches :) 2024-02-07 13:58:20 yeah, and whatnot... 2024-02-07 14:02:39 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 Oh no 2024-02-07 14:04:07 hehe 2024-02-07 14:04:10 My mistake 2024-02-07 14:04:52 scudo-malloc is not patchelf'd for 32-bit ARM 2024-02-07 14:06:02 Comment says link scudo-malloc "on architectures where it works well" 2024-02-07 14:06:11 i guess that means it causes some problems for the ARM's 2024-02-07 14:06:57 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 mm... 2024-02-07 14:11:45 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 other than that, it's just cosmetics 2024-02-07 14:14:56 Oh, another thing 2024-02-07 14:15:06 i think the source files are installed into the .apk 2024-02-07 14:15:23 and i think i saw some .orig's ;) 2024-02-07 14:16:39 Just left a comment on !58129 2024-02-07 14:18:03 ๐Ÿ‘ 2024-02-07 14:18:10 I've seen .orig's too 2024-02-07 14:20:58 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 1.75.0 is aarch64 :) 2024-02-07 14:24:20 s/is/in/ 2024-02-07 14:26:04 !60356 2024-02-07 14:27:40 hehe, you are quick, thanks 2024-02-07 14:30:17 well, motivated =) 2024-02-07 14:33:34 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 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 i wonder if we can use default_*shcomp for the cargo shell completions, and just override `install_if` 2024-02-07 14:39:07 Oh but, the default pkgdesc will get $pkgname wrong 2024-02-07 14:39:12 so probably not worth it 2024-02-07 14:41:38 Maybe all the calls to tar & could go into a for loop 2024-02-07 14:44:10 Oh now there is also an MR for sbcl 2024-02-07 14:58:02 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 Rust 1.76.0-beta9 has succeeded on aarch64 2024-02-07 15:16:54 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 yeah, all but riscv64 and s390x 2024-02-07 15:38:53 celeste: quick and dirty attempt for go 1.22 !60365 2024-02-07 15:39:18 Yes, i saw that :) 2024-02-07 15:39:39 So the CI is now working on both Rust 1.76.0 (beta) and Go 1.22 2024-02-07 15:40:23 and thanks 2024-02-07 15:49:27 go 1.22 failed 32-bit arm but I requeued 2024-02-07 15:50:28 No hurry for Go 1.22, my aport upgrade can wait 2024-02-07 15:51:06 haha, rust 1.74.1 got flagged as out-of-date today 2024-02-07 15:51:59 before I think 1.73.0 was "ok" 2024-02-07 15:52:10 saw that when we went past 1.73.0 2024-02-07 15:52:18 On pkgs.a.o? 2024-02-07 15:52:35 Was it by the release-monitoring bot? 2024-02-07 15:52:49 can't tell 2024-02-07 15:53:00 but release-monitoring should have flagged earlier, no? 2024-02-07 15:53:23 Yeah, it's no longer on pkgs.a.o now 2024-02-07 15:53:24 I can only see here https://pkgs.alpinelinux.org/packages?name=rust&branch=edge&repo=&arch=&maintainer= 2024-02-07 15:54:02 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 the latest* 2024-02-07 15:56:19 Unless it was one of our users who flagged it, wanting 1.75.0 to build something :) 2024-02-07 15:59:21 and it seems removing `--target="$CTARGET"` fixes !58174 (armv7 CI passed) 2024-02-07 16:00:00 which probably means arbitrary is wrongly classified as not needed for the $CTARGET 2024-02-07 16:00:06 arbitrary, the crate, that is 2024-02-07 16:17:11 arbitrarily 2024-02-07 17:13:50 I just hope riscv64 is done building rust 1.75.0 before 1.76.0 comes out :D 2024-02-07 17:20:28 oops. commit message 2024-02-07 17:25:53 haha 2024-02-07 17:27:25 ikke: was it someone who had changed the title of the MR but not the commit message? 2024-02-07 17:27:58 nope, I wasn't paying enough attention apparently 2024-02-07 17:28:09 !60349 2024-02-07 17:28:21 It's not too bad 2024-02-07 17:28:43 well, the MR title was different, yes 2024-02-07 17:29:45 I've merged worse 2024-02-07 17:29:51 probably you too :D 2024-02-07 17:29:55 yup 2024-02-07 17:30:20 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 :D 2024-02-07 17:30:27 haha, yes 2024-02-07 18:32:34 huh? 2024-02-07 18:32:40 algitbot: retry master 2024-02-07 19:44:09 out of memory allocating 135266296 bytes after a total of 65536 bytes 2024-02-07 19:44:11 humm 2024-02-07 20:33:49 the kernel doesn't usually fail to build on just x86 does it? 2024-02-07 20:34:42 No, it doesn't 2024-02-07 20:38:38 ncopa: 2024-02-07 21:46:43 soon riscv64 will start building rust 1.75.0! 2024-02-07 21:48:09 there 2024-02-07 23:10:22 let's see if we have better luck this time 2024-02-07 23:21:00 *sigh* 2024-02-07 23:37:36 omni: i assume you tried the TEST_TEMP_RETAIN thingy it mentions in the log? 2024-02-07 23:37:49 not that it would change much, i think 2024-02-07 23:38:25 my current plan is to disable the offending test 2024-02-07 23:38:34 !60379 2024-02-07 23:39:14 but seems like space ran out on the x86_64 CI builder 2024-02-07 23:39:39 but also, that test is immensely cursed 2024-02-07 23:41:18 https://gitlab.torproject.org/tpo/core/arti/-/issues/1264#note_2993649 2024-02-07 23:44:56 remind me, it succeeds locally and on the CI, but fails on the builders? 2024-02-07 23:46:02 yes 2024-02-07 23:46:29 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 ah, no, it does 2024-02-07 23:49:30 makes sense? 2024-02-07 23:50:33 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 ๐Ÿฎฒpanic๐Ÿฎณ๐Ÿฎฒ101๐Ÿฎณ 2024-02-07 23:53:26 wha- 2024-02-07 23:53:41 is it just me or is that some garbled unicode 2024-02-07 23:54:04 but also, hm, on x86_64 the dbg! macro from line 600 does run properly 2024-02-07 23:55:04 U+1FBB2 & U+1FBB3 2024-02-07 23:55:21 ๐Ÿฎฒ๐Ÿฎณ 2024-02-07 23:55:44 my terminal doesn't print it too well... 2024-02-07 23:56:06 but I like broken unicode too 2024-02-07 23:58:41 ptrc: huh? 2024-02-08 00:00:46 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 ptrc: yeah, idk 2024-02-08 01:20:08 maybe someone is using the gitlab CI to mine shitcoins 2024-02-08 01:21:34 Is it really slow again? 2024-02-08 01:30:20 https://releases.rs/ has been updated to list 1.76.0 as Rust stable 2024-02-08 01:31:37 i wonder if it isn't just an automated thing though, that happens after midnight UTC 2024-02-08 01:34:16 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 it's not here https://static.rust-lang.org/dist/rustc-1.76.0-src.tar.xz 2024-02-08 01:35:22 nor here https://github.com/rust-lang/rust/releases 2024-02-08 01:35:31 yet 2024-02-08 01:36:57 maybe it's not crypto pyramid scheme mining but just browser engines 2024-02-08 01:47:21 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 oh-no! 2024-02-08 01:51:00 It's in main!! 2024-02-08 01:51:01 but it was done with rust 1.75.0 2024-02-08 01:51:08 but has it been uploaded? 2024-02-08 01:51:21 I don't think it has if something else is blocking 2024-02-08 01:51:41 algitbot: retry master 2024-02-08 01:52:20 Ugh, vapigen terminated 2024-02-08 01:52:42 i've seen this with NetworkManager (or was it ModemManager) on 32-bit 2024-02-08 01:53:40 algitbot: retry master 2024-02-08 01:54:23 signal 11, isn't that a segfault? 2024-02-08 01:55:10 One more time 2024-02-08 01:55:11 algitbot: retry master 2024-02-08 01:56:19 i wonder if i mentioned anywhere the error i got from NetworkManager 2024-02-08 01:56:43 Yeap, signal 11 2024-02-08 01:56:54 Logs for this channel for November last year 2024-02-08 01:57:00 algitbot: retry master 2024-02-08 01:57:13 i can reproduce the segfault locally 2024-02-08 01:57:17 let me try and get a stacktrace 2024-02-08 01:57:50 but i don't think anyone did anything to make NetworkManager build 2024-02-08 01:58:04 it just sort of succeeded after many retries 2024-02-08 01:58:30 Oh wait, s/November/October/ 2024-02-08 01:58:46 algitbot: retry master 2024-02-08 02:00:12 ah 2024-02-08 02:00:14 i segfaulted gdb 2024-02-08 02:00:18 trying to open the coredump 2024-02-08 02:00:31 that's not good 2024-02-08 02:00:48 algitbot: retry master 2024-02-08 02:00:55 What does that usually mean? 2024-02-08 02:02:00 i'm worried that something might be more broken than we think 2024-02-08 02:02:10 In riscv64? 2024-02-08 02:02:24 or other archs as well? 2024-02-08 02:02:40 rv64 2024-02-08 02:02:45 haven't seen a gdb segfault in ages 2024-02-08 02:02:52 and lldb doesn't build for rv64 2024-02-08 02:02:55 Ok 2024-02-08 02:03:06 Maybe you could try building libsecret 0.21.2 on riscv64 2024-02-08 02:03:22 That succeeded on the builder 2024-02-08 02:03:32 2 months ago 2024-02-08 02:03:42 sure, lemme try 2024-02-08 02:04:00 Thanks :) 2024-02-08 02:04:09 algitbot: retry master 2024-02-08 02:04:40 same thing 2024-02-08 02:04:58 i wonder if i can copy the segfault to x86_64 and try viewing the stacktrace there somehow 2024-02-08 02:06:35 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 and we haven't had a vala upgrade since then 2024-02-08 02:07:03 perhaps it's not related to vala after all 2024-02-08 02:07:14 Ok 2024-02-08 02:08:08 okay, i get the same segfault in gdb when running gdb-multiarch on my pc 2024-02-08 02:08:11 sigh 2024-02-08 02:10:21 ah! 2024-02-08 02:10:26 it's not vapigen nor anything 2024-02-08 02:10:30 it's qemu-riscv64 that's segfaulting 2024-02-08 02:11:09 That can't be good 2024-02-08 02:11:09 we still don't have native riscv64 builders ( soon? ), so we use userspace emulation 2024-02-08 02:13:19 Yes, you've mentioned that before :) 2024-02-08 02:17:40 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 yeah, it would 2024-02-08 02:22:10 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 Would something that work? 2024-02-08 02:22:40 oh, we did that because of some dumb issue before 2024-02-08 02:23:06 we.. could do that again, i guess? 2024-02-08 02:23:17 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 heh.. 2024-02-08 02:28:25 >>> qemu-dbg*: Running split function dbg... 2024-02-08 02:28:25 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 >>> ERROR: qemu-dbg*: dbg failed 2024-02-08 02:28:28 welp. 2024-02-08 02:28:41 here goes 20 minutes of building 2024-02-08 02:36:34 or maybe it's not qemu? 2024-02-08 02:36:36 i'm so confused 2024-02-08 02:36:48 anything i try throwing at it segfauklts 2024-02-08 02:36:52 segfaults* 2024-02-08 02:39:19 nevermind 2024-02-08 02:39:33 turns out binfmt somehow cached(?) the qemu-riscv64 executable 2024-02-08 02:39:42 i replaced it with debian's qemu-static-riscv64 and that works just fine 2024-02-08 02:39:55 so it's an issue with our qemu, or perhaps some kind of regression 2024-02-08 02:40:09 Ok 2024-02-08 02:41:06 yeah 2024-02-08 02:41:11 arch also has 8.2.0 2024-02-08 02:41:16 and it also segfaults 2024-02-08 02:41:26 !60392 2024-02-08 02:41:32 but debian's 7.2.7 works 2024-02-08 02:41:52 in case you wanted to do that 2024-02-08 02:41:54 omni: do we really have a lot of packages pending on rv64 though? 2024-02-08 02:42:12 We are mainly waiting for Rust 1.75.0 to get uploaded 2024-02-08 02:42:17 ohhhhhhh 2024-02-08 02:42:24 then sure, yeah 2024-02-08 02:42:38 So it can build 1.76.0 that should be out today 2024-02-08 02:42:53 tbf i'm all for weird hacks, as long as they get us going somewhere :p 2024-02-08 02:43:40 Speaking of weird hacks 2024-02-08 02:43:48 rpm 4.19.1.1 was released 2024-02-08 02:44:15 Is there a shell expression to get 4.19? 2024-02-08 02:44:39 ${pkgver%*.*} worked when it was only 4.19.1 2024-02-08 02:45:46 i don't think so? 2024-02-08 02:46:21 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 Ok 2024-02-08 02:46:30 not without shelling out to some tool 2024-02-08 02:46:31 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 i guess i'll just hard code 4.19 into the source URL for the time being 2024-02-08 02:47:09 or something sed or awk or something 2024-02-08 02:47:20 where was it that was done recently? 2024-02-08 02:47:30 cely: better make another variable below pkgver 2024-02-08 02:47:39 makes it easier to spot when upgrading :p 2024-02-08 02:49:26 Any suggestion for what to call it? 2024-02-08 02:50:26 or look at main/linux-lts/APKBUILD, for example 2024-02-08 02:50:34 omni: i don't think using sed or awk in the global scope is encouraged 2024-02-08 02:51:09 Ah ok, linux-lts uses case to decide 2024-02-08 02:51:16 Thanks for that suggestion 2024-02-08 02:51:52 np, thought I had seen something like it somewhere 2024-02-08 02:51:57 Still, what should i name the variable? _majorver? 2024-02-08 02:53:58 Wait, using case still doesn't give an expression that returns 4.19 from 4.19.1.1 2024-02-08 02:54:37 cely: ${pkgver%*.*.*} 2024-02-08 02:55:07 or, actually, without the first asterisk 2024-02-08 02:55:55 Ok thanks 2024-02-08 02:56:52 with the case you could do something diferent depending on number of digits 2024-02-08 02:58:05 Yes 2024-02-08 03:01:57 https://gitlab.com/qemu-project/qemu/-/issues/1908 2024-02-08 03:01:59 perhaps related? 2024-02-08 03:04:41 I'll get that fake downgrade in 2024-02-08 03:08:40 hehe, at least we have Rust 1.75.0 on riscv64 now 2024-02-08 03:12:19 !60394 to keep track of it 2024-02-08 03:13:36 thank you both for carrying out this massive rust upgrade chain <3 2024-02-08 03:13:36 oh, btw, because i didn't get the chance to do so yet 2024-02-08 03:13:55 You're welcome 2024-02-08 03:14:11 Thanks to omni too for helping out 2024-02-08 03:15:07 omni would get the MR in proper shape for merging, while i tried out the next Rust version :) 2024-02-08 03:15:46 yeah, team effort 2024-02-08 03:16:34 !60393 in case anyone is interested in how i did the pkgver thing 2024-02-08 03:17:11 Also, why is abuild complaining that "popt-dev should be removed from depends_dev"? 2024-02-08 03:17:55 and when they release version 5? 2024-02-08 03:18:55 Hmm, i guess the "popt-dev" thing is due to pc:popt being auto-traced 2024-02-08 03:18:58 cely: it's auto-traced from the pc: 2024-02-08 03:18:59 yeah 2024-02-08 03:21:33 https://ftp.osuosl.org/pub/rpm/releases/historical/rpm-3.0.x/ 2024-02-08 03:21:42 So they have historically done an rpm-3.0 release 2024-02-08 03:21:59 and 4.0 as well, guess i better account for that 2024-02-08 03:25:06 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 :D 2024-02-08 03:28:06 ๐ธ.๐Ÿ 2024-02-08 03:28:36 https://ptrc.gay/gRjnkBoY 2024-02-08 03:28:40 omni: is your terminal okay? :p 2024-02-08 03:28:57 ( mostly just curious where are those coming from ) 2024-02-08 03:29:04 perfectly fine, does that not render at your end? 2024-02-08 03:29:24 it renders just as on the screenshot 2024-02-08 03:29:29 i see . 2024-02-08 03:29:36 not the thing before the . 2024-02-08 03:29:51 the second one is a domino piece 2024-02-08 03:30:07 and the first is.. "TALLY MARK FIVE" according to unicode 2024-02-08 03:30:13 Ah right, domino 2024-02-08 03:30:39 I'm just looking into the future of version numbering 2024-02-08 03:30:57 uni print all | sk -e | cut -d \' -f 2 | wl-copy -p -n 2024-02-08 03:31:25 is what I'm using to search for various fun unicode 2024-02-08 03:31:27 oh lol 2024-02-08 03:31:33 Is that how you found your Github profile description? 2024-02-08 03:33:00 https://github.com/omnivagant ? 2024-02-08 03:33:17 "The wanderer" 2024-02-08 03:33:35 ah, yes 2024-02-08 03:33:52 forgot about that 2024-02-08 03:34:01 :) 2024-02-08 03:36:43 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 algitbot: retry master 2024-02-08 06:24:27 algitbot: retry master 2024-02-08 06:30:25 algitbot: retry master 2024-02-08 06:36:58 algitbot: retry master 2024-02-08 06:42:36 algitbot: retry master 2024-02-08 06:50:29 algitbot: retry master 2024-02-08 07:05:57 algitbot: retry master 2024-02-08 07:12:19 algitbot: retry master 2024-02-08 07:26:29 \o/ 2024-02-08 07:48:05 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 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 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 omni: https://blog.rust-lang.org/2024/02/08/Rust-1.76.0.html it's been released 2024-02-08 14:43:50 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 celie: already saw 2024-02-08 14:46:13 but thanks! 2024-02-08 14:49:52 celie: it's merged now ;) 2024-02-08 19:03:10 \o/ 2024-02-08 19:26:22 https://appealforassistance.notion.site/Appeal-for-Assistance-abcca31346e944b38e09ebabb4208152 2024-02-08 21:04:06 algitbot: retry master 2024-02-08 21:17:51 algitbot: retry 3.19-stable 2024-02-09 00:36:16 cool 2024-02-09 00:42:27 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 So, the QEMU segfaulting issue was actually a pcre2 issue? 2024-02-09 01:45:35 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 celie: yup, but *technically* also a qemu issue 2024-02-09 01:50:04 Oh wow, some activity from @ScrumpyJack (#15766) 2024-02-09 01:54:11 and the reply for that package request is that it's pretty much undoable, hehe 2024-02-09 01:54:35 Anyway, has there ever been an attempt at packaging rust-nightly? 2024-02-09 01:59:32 not that I know of 2024-02-09 01:59:53 what would it be for? 2024-02-09 02:00:11 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 to be ahead of and prepared for releases? 2024-02-09 02:01:06 omni: Yes :) 2024-02-09 02:01:13 ayakael: since you made me aware of that MR 2024-02-09 02:03:42 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 but how do I know where to get one? 2024-02-09 02:04:26 Well, with nightly we would get to prepare 2 releases ahead :) 2024-02-09 02:05:02 yeah... 2024-02-09 02:05:07 and i've realized something 2024-02-09 02:05:22 that you want to maintain rust? ;) 2024-02-09 02:05:35 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 There's actually something better 2024-02-09 02:06:16 the suspense 2024-02-09 02:06:28 A pre-release: https://blog.rust-lang.org/inside-rust/2024/02/04/1.76.0-prerelease.html 2024-02-09 02:06:43 So, i guess there is a reason for everything 2024-02-09 02:07:07 The day Rust beta became 1.77.0 was the day Rust 1.76.0 got a prerelease 2024-02-09 02:07:43 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 wondering* 2024-02-09 02:08:17 (as it's in none of the normal release channels: stable, beta, nightly) 2024-02-09 02:08:36 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 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 For 1.77.0, you may try the latest Rust beta 2024-02-09 02:10:32 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 is my mistake looking for a 1.77.0 beta and not just a beta? 2024-02-09 02:10:54 What do you mean? 2024-02-09 02:11:54 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 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 yeah, I think I'm catching on 2024-02-09 02:13:09 but that toml file was a good resource 2024-02-09 02:15:20 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 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 but I've also been thinking if maintaining rust could/should be shared 2024-02-09 02:21:10 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 s/RAM/ARM/ 2024-02-09 02:21:26 haha 2024-02-09 02:21:59 omni: if you're gonna start a rust team in alpine, count me in :p 2024-02-09 02:22:04 Maintaining lots of things could benefit from being shared 2024-02-09 02:22:43 ( 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 also for getting upgrades/changes in 2024-02-09 02:22:54 ptrc: sure! 2024-02-09 02:23:43 but we can kinda deal with team things anyway, can't we? 2024-02-09 02:25:00 yeah, the bot makes things a bit easier 2024-02-09 02:30:03 i wonder if this channel is becoming #alpine-rust 2024-02-09 02:30:56 more like #alpine-build-failures :p 2024-02-09 02:31:11 (would probably be good to have a channel, if a team for it is started) 2024-02-09 02:49:04 yeah 2024-02-09 02:50:29 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 Let's hope it continues till the end 2024-02-09 02:50:48 s/then/than/ 2024-02-09 02:52:50 Oops, it failed 2024-02-09 02:53:35 "Illegal instruction", and i spoke too soon, looks like it's still failing at the same spot 2024-02-09 02:55:04 https://gitlab.alpinelinux.org/Celeste/aports/-/jobs/1271208 in case anyone is interested 2024-02-09 02:55:22 Anyway, i guess it is back to using the bytecode compiler for riscv64 2024-02-09 02:57:20 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 could we add it as ocaml5 for now? 2024-02-09 02:59:38 What do you mean? 2024-02-09 02:59:39 to have it available but not move from ocaml 4 just yet 2024-02-09 02:59:50 It is testing/ocaml5 2024-02-09 03:00:07 but version 5.2 is currently in alpha 2024-02-09 03:00:15 oh, I'm tired and haven't thought about this for a while 2024-02-09 03:01:06 Currently, it has an unversioned `provides=ocaml` 2024-02-09 03:01:16 i wonder if that should just be removed 2024-02-09 03:01:36 since 4 and 5 are not really interchangeable 2024-02-09 03:02:16 as in, OCaml 4 aports wanting `ocaml` cannot simply use OCaml 5 2024-02-09 03:02:51 and it is unversioned anyway, so apk will not auto-select it 2024-02-09 03:03:54 (even if you comment out community in /etc/apk/repositories where OCaml 4 is) 2024-02-09 03:06:34 I need to get back to thinking about that some other time 2024-02-09 03:11:21 look at it fail !60488 2024-02-09 03:11:32 time to give up 2024-02-09 03:12:30 Ah! 2024-02-09 03:12:30 lol 2024-02-09 03:12:42 i actually have a patch for that 2024-02-09 03:12:54 Let me see if i can dig it up 2024-02-09 03:13:21 (could've been rebased away in one of my branches) 2024-02-09 03:15:26 did you push it at any time? 2024-02-09 03:16:29 also not sure about need-ssp_nonshared.patch, but library/std/src/sys/unix/mod.rs is gone 2024-02-09 03:16:37 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/60488/diffs#diff-content-8336ac0830e2405a5d72e350241622a935e85e81 2024-02-09 03:16:40 Sure, but i have the bad habit of reusing old branches to test CI 2024-02-09 03:17:02 Let me get you the patch for that as well 2024-02-09 03:17:39 I think I need to look at it at a later time 2024-02-09 03:17:48 but comment here or in the MR 2024-02-09 03:18:18 https://gitlab.alpinelinux.org/Celeste/aports/-/blob/45c8c7d8e3/main/rust/no-rustfmt-dist-file.patch 2024-02-09 03:18:39 You will probably need to amend the "date" field 2024-02-09 03:22:20 check 2024-02-09 03:22:23 https://gitlab.alpinelinux.org/Celeste/aports/-/commit/22c5da5ccf 2024-02-09 03:22:26 1970-01-01 2024-02-09 03:22:40 My changes from when i accidentally used 1.77.0 thinking it was a 1.76.0 beta 2024-02-09 03:23:54 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 and bootstrap-vendor-remap.patch has been upstreamed 2024-02-09 03:26:37 i see you've already handled bootstrap-vendor-remap.patch in your MR 2024-02-09 03:36:12 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 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 ouch, I'll look at that in an hour or two 2024-02-09 18:44:29 I'm looking at that issue in !60524 2024-02-10 02:42:16 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 I think Kladky was almost 1 step away from claiming main/rust in !60344 2024-02-10 02:53:35 and now they're claiming cargo-auditable and rust-analyzer :) 2024-02-10 03:09:29 algitbot: retry master 2024-02-10 03:10:08 algitbot: retry master 2024-02-10 03:11:29 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 yes 2024-02-10 03:14:45 fgt I haven't looked at 2024-02-10 03:16:09 the other I'm looking at in !60524 and !6534 2024-02-10 03:16:19 uhm, no.. 2024-02-10 03:16:28 !60534 2024-02-10 03:16:38 ther we go 2024-02-10 03:17:02 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 it's taking so long... 2024-02-10 03:17:36 to compare with test output from the first one before I disabled tests for llvm17 with the patch 2024-02-10 03:20:16 Alright 2024-02-10 03:26:40 you're welcome to have a look if you want 2024-02-10 03:46:33 Ah that's why i couldn't get a riscv64 CI :) 2024-02-10 03:46:45 both these MRs are running that 2024-02-10 23:06:40 algitbot: retry master 2024-02-11 00:40:27 algitbot: retry master 2024-02-11 03:08:25 ptrc: !60624 2024-02-11 03:09:04 thanks! 2024-02-11 03:09:20 np 2024-02-11 03:10:17 Regarding mcookie 2024-02-11 03:10:31 Did you have a look at what requires that? 2024-02-11 03:10:34 Is it xvfb? 2024-02-11 03:12:03 or more specifically, xvfb-run 2024-02-11 03:12:13 Line 155 of /usr/bin/xvfb-run? 2024-02-11 03:13:47 Yes, just looked at the error log on build.a.o 2024-02-11 03:13:57 Perhaps mcookie should be added to xvfb-run instead? 2024-02-11 03:15:12 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 I also remembered seeing mcookie being added to a checkdepends recently 2024-02-11 03:17:21 cely: ah, that was you 47ee2076d35f6004fbbb2bb22f100c534c53287a 2024-02-11 03:18:39 Hmm, i just tested one of my aports that uses xvfb-run for tests (perl-tkx) 2024-02-11 03:18:45 and now it fails to find mcookie 2024-02-11 03:19:59 wait 2024-02-11 03:20:14 https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/perl-tkx/perl-tkx-1.10-r0.log 2024-02-11 03:20:33 mcookie was installed when it built on the builders 2024-02-11 03:21:35 something was changed recently.. 2024-02-11 03:22:44 I wonder what changed 2024-02-11 03:24:00 less things depend on xinit... 1fd2d70696b88a0605ad5771137da148c998c192 2024-02-11 03:24:07 xinit depend on mcookie 2024-02-11 03:24:14 but could that really be it? 2024-02-11 03:24:28 for firefox maybe 2024-02-11 03:26:12 Yes, that's probably it 2024-02-11 03:26:17 but looking at the xvfb-run script, it looks like it should depend on mcookie, doesn't it? 2024-02-11 03:27:39 Yes 2024-02-11 03:28:49 xvfb is a subpackage of community/xorg-server, and so inherits its depends= 2024-02-11 03:29:12 which is why mcookie is no longer installed 2024-02-11 03:32:36 ๐Ÿ‘ 2024-02-11 03:32:43 I'm working on an MR 2024-02-11 03:33:06 I wonder what else could be broken as a result of removing xinit as dependency 2024-02-11 03:36:37 yes... 2024-02-11 03:36:59 any issues about it? 2024-02-11 03:38:05 Not sure, the MR removing the xinit dep did get a thumbs down 2024-02-11 03:41:07 tigervnc already depends on xinit, so that's taken care of 2024-02-11 03:41:37 (I'm guessing the things that could break are scripts like xvfb-run) 2024-02-11 03:44:45 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 is there any way to see when a ๐Ÿ‘Ž ? 2024-02-11 03:48:14 thinking it may have been a reaction to what it led to 2024-02-11 03:49:17 What do you mean? A search filter to list all MRs with thumbs-downs? 2024-02-11 03:50:31 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 or do you mean finding the timestamp for the thumbs-down? 2024-02-11 03:50:45 doesn't matter much 2024-02-11 03:51:13 I think I'm gonna merge !60625 now, would you like to have a quick peek? 2024-02-11 03:51:45 of course it's building all the things 2024-02-11 03:52:04 The Gitlab API could show you the time of the emoji reaction 2024-02-11 03:52:17 I've looked, it looks good 2024-02-11 03:52:26 So, it seems gajim also encountered this issue 2024-02-11 03:52:29 great, let's 2024-02-11 03:56:10 lomiri-content-hub too, do you see any more? 2024-02-11 03:59:53 No, don't see anything else 2024-02-11 04:06:04 I wonder if anything else broke 2024-02-11 04:07:00 I'm all for removing dependencies 2024-02-11 04:07:04 and it seems Rust 1.77.0 beta has passed CI for a couple of archs 2024-02-11 04:07:12 w00t 2024-02-11 04:08:26 On x86_64: "Size difference for rust: 560 MiB -> 524 MiB" 2024-02-11 04:09:03 I wonder if that's just due to the beta having less things included, but probably not 2024-02-11 05:15:52 Another MR affected by missing mcookie: !60630 2024-02-11 05:16:50 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 algitbot: retry master 2024-02-11 05:45:41 algitbot: retry master 2024-02-11 05:46:35 Finally, the builders are building something else that doesn't depend on fgt and libjxl 2024-02-11 05:47:17 Hopefully, one or two more retries will further cut down the number of pending aports 2024-02-11 05:47:22 algitbot: retry master 2024-02-11 05:47:55 algitbot: retry master 2024-02-11 05:49:26 algitbot: retry master 2024-02-11 05:51:05 algitbot: retry master 2024-02-11 05:52:24 I guess that's it 2024-02-11 12:43:56 omni: I would say yes to your question in !60477 2024-02-11 12:52:40 I assumed so, it was also a way of pingingthem 2024-02-11 13:13:48 mmm... cookies... https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/60586/diffs?diff_id=877087&start_sha=653676758d95c5082853e5e41336934d33ad827c 2024-02-11 13:28:22 algitbot: retry master 2024-02-11 13:33:46 algitbot: retry master 2024-02-11 13:57:12 "QSYSTEM: InstallationTest::testInstallCommand() kf.newstuff.core: Could not determine type of archive file '"/tmp/PNdHti-testfile.txt"'" 2024-02-11 13:57:14 algitbot: retry master 2024-02-11 14:02:35 ACTION hopes jirutka will take time to look at !54061 2024-02-11 14:15:01 algitbot: retry master 2024-02-11 14:34:38 algitbot: retry master 2024-02-11 15:19:13 algitbot: retry master 2024-02-11 15:23:12 algitbot: retry master 2024-02-11 15:24:32 algitbot: retry master 2024-02-11 15:25:13 Ha, there's still frameworkintegration5 that isn't blocked by fgt that s390x can build 2024-02-11 15:25:58 Probably nothing left, but one more last retry 2024-02-11 15:26:31 algitbot: retry master 2024-02-11 15:27:06 Now it's building plasma-framework5 2024-02-11 15:29:28 and krunner5 and postgresql13 2024-02-11 15:29:38 So, i wonder how many aports are actually blocked by fgt on s390x 2024-02-11 15:31:53 Looking through the log, i mentioned 3 aports 2024-02-11 15:35:29 i mean, just the number 3, didn't look further into which aports specifically 2024-02-11 15:35:47 algitbot: retry master 2024-02-11 15:36:21 algitbot: retry master 2024-02-11 15:39:10 algitbot: retry master 2024-02-11 15:41:42 390x) ctest --test-dir build --output-on-failure -E "cluster";; 2024-02-11 15:41:54 could it be that it is failing due to that? 2024-02-11 15:42:17 fgt? 2024-02-11 15:42:29 wait, that case statement is wrong 2024-02-11 15:42:30 algitbot: retry master 2024-02-11 15:42:40 it should be s390x, not 390x 2024-02-11 15:42:47 *sigh* 2024-02-11 15:42:48 Yes 2024-02-11 15:42:59 I'll fix 2024-02-11 15:43:11 but how did it pass in CI? 2024-02-11 15:43:20 You initially thought it was failing because it executed that? 2024-02-11 15:43:48 no, because it was missing something because that was excluded 2024-02-11 15:44:07 like a test depending on something with that test, idk 2024-02-11 15:44:20 Ah yes, cluster fails, looking at the build log 2024-02-11 15:44:20 lol 2024-02-11 15:44:37 So, we were sitting here wondering what was wrong but never looked deeper 2024-02-11 15:46:49 I think the s390x CI was skipped for !60517 2024-02-11 15:47:31 and then the commit disabling the failing test was merged without going through CI 2024-02-11 15:48:00 So, nobody caught the typo until now :) 2024-02-11 15:48:46 Yay, it's finally fixed now 2024-02-11 15:48:54 \o/ 2024-02-11 15:49:15 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 nice work 2024-02-11 15:49:46 I wonder how many aports in testing s390x will need to catch up with 2024-02-11 15:49:48 I did poke him about it as soon after it showed up 2024-02-11 15:50:06 and he must have thought he'd already fixed it 2024-02-11 15:51:54 yeah, sure, but he should also know to keep an eye at https://build.alpinelinux.org/ 2024-02-11 15:54:51 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 you missed the s in s390x =) 2024-02-11 16:25:51 algitbot: retry master 2024-02-11 16:36:29 algitbot: retry master 2024-02-12 04:48:27 The s390x CI seems to be acting up again 2024-02-12 13:41:33 algitbot: retry master 2024-02-12 13:43:25 algitbot: retry master 2024-02-12 14:13:30 finger crossings 2024-02-12 14:14:12 :) 2024-02-12 14:18:37 algitbot: retry master 2024-02-12 14:41:25 algitbot: retry master 2024-02-12 14:47:44 algitbot: retry master 2024-02-12 16:02:35 algitbot: retry master 2024-02-12 16:04:36 algitbot: retry master 2024-02-13 04:13:13 algitbot: retry master 2024-02-13 04:15:06 algitbot: retry master 2024-02-13 04:56:02 algitbot: retry master 2024-02-13 04:57:37 algitbot: retry master 2024-02-13 08:28:44 algitbot: retry master 2024-02-13 08:37:03 algitbot: retry master 2024-02-13 08:39:30 algitbot: retry master 2024-02-13 11:46:25 algitbot: retry master 2024-02-13 17:00:42 algitbot: retry master 2024-02-13 22:50:26 algitbot: retry master 2024-02-13 23:51:32 uh-oh 2024-02-13 23:54:18 so the checksum shouldn't have been changed becaue it's cached 2024-02-14 02:40:20 now what 2024-02-14 02:42:02 gah 2024-02-14 02:42:10 I was about to afk 2024-02-14 02:43:03 Hmm 2024-02-14 02:43:18 Does it need bash back in checkdepends? 2024-02-14 02:46:21 hmm.. maybe.. 2024-02-14 02:46:38 It's SIGSEGV though 2024-02-14 02:47:06 yeah, just checked on a CI build and bash wasn't installed there... 2024-02-14 02:47:30 Bash was just removed with this upgrade 2024-02-14 02:49:37 I wonder if bash is installed on the CI runners, but probably not 2024-02-14 02:49:43 yes, but tests were run in CI three days ago 2024-02-14 02:50:26 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 Did we have a Rust upgrade in between the runs on CI and builder? 2024-02-14 02:51:43 Yes we did 2024-02-14 02:52:04 wasn't that earlier? 2024-02-14 02:52:04 3 days ago was for riscv64, which didn't complete tests 2024-02-14 02:52:09 The other archs was 6 days ago 2024-02-14 02:52:32 ah 2024-02-14 02:53:12 So, Rust 1.74.1 vs 1.76.0 2024-02-14 02:53:13 looks like it built with rust 1.74.1 2024-02-14 02:53:43 At least we can rule out llvm16 2024-02-14 02:55:13 algitbot: retry master 2024-02-14 02:58:41 algitbot: retry master 2024-02-14 03:00:18 since it failed the same way, I think, on all the builders, my expectations are low 2024-02-14 03:00:35 Yeah, same here 2024-02-14 03:02:49 algitbot: retry master 2024-02-14 03:04:54 algitbot: retry master 2024-02-14 03:06:11 Results should be coming in any time now 2024-02-14 03:06:58 the only thing I can think of right now is to just disable the tests 2024-02-14 03:07:27 because I can't stay much longer now 2024-02-14 03:07:51 Just nu-path or !check? 2024-02-14 03:08:40 Did it just pass on armhf? 2024-02-14 03:09:52 and aarch64 too 2024-02-14 03:10:14 Flaky tests will be flaky 2024-02-14 03:10:23 algitbot: retry master 2024-02-14 03:11:19 oh, ok.. 2024-02-14 03:11:42 algitbot: retry master 2024-02-14 03:12:05 I guess i'll keep retrying for a while, at least 2 ARM's are now unblocked 2024-02-14 03:12:13 So you can go AFK if you want 2024-02-14 03:12:48 are you sure? 2024-02-14 03:12:49 algitbot: retry master 2024-02-14 03:13:17 I mean, that it's fine to sit and do that 2024-02-14 03:13:18 Is anything certain when it comes to software? :D 2024-02-14 03:13:28 algitbot: retry master 2024-02-14 03:13:33 Keep retrying? 2024-02-14 03:13:40 yeah 2024-02-14 03:13:46 Most probably yes, maybe for the next half an hour or so 2024-02-14 03:14:37 because I almost clicked "Create merge request" on one that would !check 2024-02-14 03:14:44 hehe 2024-02-14 03:14:56 algitbot: retry master 2024-02-14 03:15:07 Maybe that's fine too 2024-02-14 03:15:30 I created it 2024-02-14 03:15:32 We'll just let this run determine whether it's built with this commit or the new one 2024-02-14 03:15:45 !60811 2024-02-14 03:16:18 algitbot: retry master 2024-02-14 03:17:33 as a compromise, ask someone to merge the above when you give up 2024-02-14 03:18:08 Alright 2024-02-14 03:18:16 <3 2024-02-14 03:18:26 Bye 2024-02-14 03:18:27 *poff* 2024-02-14 03:19:40 algitbot: retry master 2024-02-14 03:21:17 algitbot: retry master 2024-02-14 03:24:42 algitbot: retry master 2024-02-14 03:25:03 Now armv7 has passed :) 2024-02-14 03:26:00 Hopefully at least one of the x86* will pass next 2024-02-14 03:28:51 algitbot: retry master 2024-02-14 03:30:45 Hi ptrc, !59032 should be ready. However, the x86_64 CI is busy building Chromium or something 2024-02-14 03:32:21 Looks like it's is only x86_64 left that hasn't finished nushell :) 2024-02-14 03:32:32 s/is// 2024-02-14 03:39:40 algitbot: retry master 2024-02-14 03:41:03 algitbot: retry master 2024-02-14 03:42:32 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 Apparently, not 2024-02-14 03:43:20 algitbot: retry master 2024-02-14 03:43:27 algitbot: retry master 2024-02-14 03:45:15 algitbot: retry master 2024-02-14 03:46:42 algitbot: retry master 2024-02-14 03:49:01 algitbot: retry master 2024-02-14 03:52:35 algitbot: retry master 2024-02-14 03:53:57 algitbot: retry master 2024-02-14 03:58:31 \o/ 2024-02-14 03:58:33 algitbot: retry master 2024-02-14 04:00:34 algitbot: retry master 2024-02-14 04:04:30 algitbot: retry master 2024-02-14 04:06:01 algitbot: retry master 2024-02-14 05:09:27 https://github.com/llvm/llvm-project/issues/64102 ? 2024-02-14 08:50:23 iggy: exactly that one, yes 2024-02-14 08:51:25 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/60608 2024-02-14 16:19:03 I was about to merge that! 2024-02-14 16:19:06 :D 2024-02-14 16:20:32 ptrc: btw, I'm holding off with !60793 until build-edge-x86_64 is done with chromium 2024-02-14 16:21:07 alrighty, makes sense 2024-02-14 16:21:25 ( are those the same machine? i always forget ) 2024-02-14 16:21:30 yes 2024-02-14 16:21:38 we usually have a single machine per arch 2024-02-14 16:21:52 (and a separate CI host if available) 2024-02-14 16:25:48 :O 2024-02-14 16:26:11 algitbot: retry master 2024-02-14 16:26:39 "process out of memory" 2024-02-14 16:26:39 Hmm 2024-02-14 16:26:43 yes 2024-02-14 16:29:26 algitbot: retry master 2024-02-14 16:32:26 algitbot: retry master 2024-02-14 16:35:27 algitbot: retry master 2024-02-14 17:02:28 algitbot: retry master 2024-02-14 17:13:25 #x86, armv7: webpack: JavaScript heap out of memory 2024-02-14 17:13:30 arch="noarch !riscv64 !x86 !armv7" 2024-02-14 17:13:37 maybe disable on armhf too 2024-02-14 17:40:14 !59991 2024-02-14 18:17:27 algitbot: retry master 2024-02-15 02:16:47 algitbot: retry master 2024-02-15 02:18:18 algitbot: retry master 2024-02-15 02:21:10 algitbot: retry master 2024-02-15 02:23:03 algitbot: retry master 2024-02-15 02:42:46 algitbot: retry master 2024-02-15 02:43:44 I was hoping riscv64 would start compiling nodejs-current, but instead it gets quickjs :) 2024-02-15 02:56:16 algitbot: retry master 2024-02-15 02:57:35 algitbot: retry master 2024-02-15 02:59:12 algitbot: retry master 2024-02-15 03:08:39 algitbot: retry master 2024-02-15 03:18:55 algitbot: retry master 2024-02-15 03:24:49 algitbot: retry master 2024-02-15 03:26:16 algitbot: retry master 2024-02-15 15:03:31 algitbot: retry master 2024-02-15 15:06:29 algitbot: retry master 2024-02-16 01:18:46 algitbot: retry master 2024-02-16 02:21:51 algitbot: retry master 2024-02-16 02:28:35 algitbot: retry master 2024-02-16 02:42:50 algitbot: retry master 2024-02-16 03:02:45 algitbot: retry master 2024-02-16 03:03:44 algitbot: retry master 2024-02-16 03:37:25 algitbot: retry master 2024-02-16 03:41:00 algitbot: retry master 2024-02-16 04:04:48 algitbot: retry master 2024-02-16 04:12:10 algitbot: retry master 2024-02-16 04:19:40 algitbot: retry master 2024-02-16 04:25:35 algitbot: retry master 2024-02-16 04:28:45 algitbot: retry master 2024-02-16 04:31:44 algitbot: retry master 2024-02-16 04:46:27 algitbot: retry master 2024-02-16 04:49:08 algitbot: retry master 2024-02-16 05:57:35 algitbot: retry master 2024-02-16 06:01:48 algitbot: retry master 2024-02-16 06:29:38 algitbot: retry master 2024-02-16 06:37:31 algitbot: retry master 2024-02-16 09:27:46 I'm working on the gwenview build failures 2024-02-16 12:21:21 algitbot: retry master 2024-02-16 12:25:56 algitbot: retry master 2024-02-16 12:57:00 algitbot: retry master 2024-02-16 13:19:47 algitbot: retry master 2024-02-16 13:41:16 algitbot: retry master 2024-02-16 13:43:06 algitbot: retry master 2024-02-16 13:46:38 algitbot: retry master 2024-02-16 13:49:33 algitbot: retry master 2024-02-16 13:58:25 algitbot: retry master 2024-02-16 14:05:38 algitbot: retry master 2024-02-16 14:08:48 algitbot: retry master 2024-02-16 14:13:56 algitbot: retry master 2024-02-17 00:30:37 I've been away longer than I thought I'd be 2024-02-17 00:36:54 perhaps we should x86* this? https://git.alpinelinux.org/aports/tree/community/py3-sqlalchemy/APKBUILD#n38 2024-02-17 00:37:24 maybe not the same thing happening 2024-02-17 00:37:52 algitbot: retry master 2024-02-17 00:38:05 algitbot: retry 3.19-stable 2024-02-17 02:11:57 algitbot: retry master 2024-02-17 02:13:18 algitbot: retry master 2024-02-17 02:19:30 algitbot: retry master 2024-02-17 02:27:16 algitbot: retry master 2024-02-17 03:01:36 algitbot: retry master 2024-02-17 03:04:31 algitbot: retry master 2024-02-17 03:15:11 algitbot: retry master 2024-02-17 03:31:05 algitbot: retry master 2024-02-17 03:58:51 algitbot: retry master 2024-02-17 04:19:04 algitbot: retry master 2024-02-17 04:32:20 algitbot: retry master 2024-02-17 04:51:55 algitbot: retry master 2024-02-17 04:59:23 algitbot: retry master 2024-02-17 05:06:44 algitbot: retry master 2024-02-17 05:13:10 algitbot: retry master 2024-02-17 05:37:31 algitbot: retry master 2024-02-17 06:04:09 algitbot: retry master 2024-02-17 06:21:04 algitbot: retry master 2024-02-17 06:31:59 algitbot: retry master 2024-02-17 06:36:10 algitbot: retry master 2024-02-17 06:37:27 algitbot: retry master 2024-02-17 06:45:49 algitbot: retry master 2024-02-17 06:52:44 algitbot: retry master 2024-02-17 06:54:05 algitbot: retry master 2024-02-17 06:57:24 algitbot: retry master 2024-02-17 06:59:20 algitbot: retry master 2024-02-17 07:10:59 algitbot: retry master 2024-02-17 12:09:18 oh-no 2024-02-17 12:17:53 hmm... -buildmode=pie requires external (cgo) linking, but cgo is not enabled 2024-02-17 12:18:50 cely: ping 2024-02-17 12:32:27 nmeum: ? 2024-02-17 14:22:17 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 So, both minio and minio-client are affected 2024-02-17 14:40:27 algitbot: retry master 2024-02-17 14:55:06 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 It seems to be passing with x86_64, aarch64, and ppc64le 2024-02-17 14:55:59 Fails on x86, 32-bit arm*, and s390x 2024-02-17 14:56:23 Didn't test riscv64, as that won't have Go 1.22 yet due to community being blocked 2024-02-17 15:00:20 https://bugs.gentoo.org/924632 2024-02-17 15:01:39 That mentions this error occurring on x86 2024-02-17 15:03:11 https://github.com/golang/go/issues/64875 mentions it on riscv64 and s390x 2024-02-17 15:07:25 https://pkgs.alpinelinux.org/packages?name=minio-client&branch=edge 2024-02-17 15:12:37 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 omni: !61018 should fix the issue 2024-02-17 15:27:10 This is going to affect a lot of other aports during the Go rebuild 2024-02-17 15:27:40 uhm, yeah... 2024-02-17 15:28:43 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 rg "CGO_ENABLED=0" | wc -l 2024-02-17 15:30:22 73 2024-02-17 15:36:25 Unfortunately, that's not true 2024-02-17 15:37:04 Some Go aports do not call `go build` directly, but use the Makefile upstream provides 2024-02-17 15:37:18 and upstream sets CGO_ENABLED=0 in that Makefile 2024-02-17 15:37:56 So, this will affect a lot more than the 73 aports that have CGO_ENABLED=0 in APKBUILD 2024-02-17 15:41:14 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 !61021 2024-02-17 16:05:43 My MR to prevent Go aports i maintain from erroring out during the big Go rebuild 2024-02-17 16:07:02 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 algitbot: retry master 2024-02-17 21:41:01 algitbot: retry master 2024-02-17 21:58:34 algitbot: retry master 2024-02-17 22:45:31 lol 2024-02-18 10:58:14 cely: https://github.com/cli/cli/issues/8668 2024-02-18 11:21:10 !61044 2024-02-19 03:43:44 too bad dotnet7 wasn't removed yet #15724 2024-02-19 13:31:26 is dotnet7-build stuck on aarch64 or just taking a very long time? 2024-02-19 13:31:39 could it be aborted since it's removed anyway? 2024-02-19 16:10:35 ikke: is dotnet7-build stuck? 2024-02-19 19:20:03 omni: apparently, yes 2024-02-19 19:20:06 algitbot: retry master 2024-02-20 01:19:02 algitbot: retry master 2024-02-20 02:51:15 algitbot: rerty master 2024-02-20 02:51:23 algitbot: retry master 2024-02-20 14:14:24 as suspected 2024-02-20 14:25:20 ok, it wasn't expected to fail on ppc64le 2024-02-20 14:26:28 algitbot: retry master 2024-02-21 01:31:05 algitbot: retry master 2024-02-21 21:27:56 algitbot: retry master 2024-02-21 21:27:59 fetch failed 2024-02-22 20:00:01 algitbot: retry master 2024-02-22 21:11:21 algitbot: retry master 2024-02-22 23:15:23 algitbot: retry master 2024-02-23 00:52:54 algitbot: retry master 2024-02-23 00:54:30 hmm.. I'm slow... 2024-02-23 00:55:09 ikke: is there any way to prioritize the build of go on riscv64? 2024-02-23 00:55:55 no, wait, its already built 2024-02-23 00:56:08 just not uploaded yet, but can be used by the builder 2024-02-23 01:43:41 algitbot: retry master 2024-02-23 02:15:35 I saw no objections 2024-02-23 03:27:37 algitbot: retry master 2024-02-23 21:49:41 algitbot: retry master 2024-02-24 03:12:51 algitbot: retry master 2024-02-24 08:26:36 algitbot: retry master 2024-02-24 12:09:42 algitbot: retry master 2024-02-24 12:50:39 algitbot: retry master 2024-02-24 12:55:13 algitbot: retry master 2024-02-24 12:56:39 rclone and hare, sitting in a tree, f a i l i n g 2024-02-24 13:01:22 ahuh 2024-02-24 13:01:55 ah, didn't get that libjxl was fixed 2024-02-24 13:05:29 yeah, ptrc fixed it with !61170 2024-02-24 13:05:44 saw the commit in the channel log 2024-02-24 13:13:45 algitbot: retry master 2024-02-24 13:30:31 algitbot: retry master 2024-02-24 13:31:41 algitbot: retry master 2024-02-24 13:32:54 algitbot: retry master 2024-02-24 13:49:43 oh-no 2024-02-24 13:49:57 ffs, I didn't look at the added commit 2024-02-24 13:49:58 ffs 2024-02-24 13:50:03 I already said that 2024-02-24 13:50:07 *sigh* 2024-02-24 13:54:20 We need a bot that checks for un-squashed commits 2024-02-24 14:07:03 shouldn't some be possible to do with git-hooks? 2024-02-24 14:07:55 Probably 2024-02-24 14:08:17 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 I saw 2024-02-24 14:20:12 # Maximal allowed size (in bytes) of a file. 2024-02-24 14:20:13 FILE_SIZE_LIMIT=262144 # 256 kiB 2024-02-24 14:20:47 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 #15812 2024-02-24 14:37:38 Not every commit affects aports though 2024-02-24 14:38:24 so we cannot force things to start with (main/community/testing)/ 2024-02-24 14:45:08 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 new files that are added to the rootdir 2024-02-24 14:47:43 We could check for '^[a-z]+:' 2024-02-24 14:48:10 We could check for '^[a-z]\S+:' 2024-02-24 14:53:34 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 git log --oneline | grep -Ev "main|community|testing|scripts|README|COMMITSTYLE|=====" 2024-02-24 14:53:43 nah 2024-02-24 14:53:46 way too rigid 2024-02-24 14:53:58 I mostly see "*/*:" and errouneous 2024-02-24 14:54:21 try git log --oneline .editorconfig .gitattributes .githooks .gitlab .gitignore .gitlab-ci.yml .mailmap 2024-02-24 14:56:05 so a bunch of reasonable things could be added to my list of things above, sure 2024-02-24 14:56:52 Or we just check that it follows a general style and don't enfore the exact words 2024-02-24 14:57:29 One tricky thing is when you push new branches 2024-02-24 14:57:38 You don't get a previous hash, so what commits do you check 2024-02-24 14:57:50 if you check all history, you will run into commits not according to style 2024-02-24 14:58:48 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 I only want to limit new commits 2024-02-24 14:59:37 or do you mean that a hook would check all history when a new branch is created? 2024-02-24 14:59:53 You don't know what commits are new and what are old 2024-02-24 15:00:30 "When creating a new ref, is the all-zeroes object name." 2024-02-24 15:06:09 could the hook be skipped when branching? 2024-02-24 15:07:17 the hook itself could detect it and allow new branches 2024-02-24 15:07:24 I mentioned that in the issue 2024-02-24 15:13:14 thanks 2024-02-24 22:00:00 whoops, wrong repo 2024-02-24 22:00:06 eh, whatever 2024-02-24 22:09:18 want me to delete the ref? 2024-02-24 22:10:52 nah, i opened a MR from it 2024-02-24 22:11:02 i'll just merge that, and it's gonna get deleted anyway :p 2024-02-24 22:30:13 ptrc: fine 2024-02-25 02:16:26 algitbot: retry master 2024-02-25 02:18:10 algitbot: retry master 2024-02-25 02:19:22 algitbot: retry master 2024-02-25 02:20:45 algitbot: retry master 2024-02-25 02:22:25 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 that commit added a conditional `CGO_ENABLED=0` for ppc64le 2024-02-25 02:34:38 algitbot: retry master 2024-02-25 02:36:15 algitbot: retry master 2024-02-25 02:36:53 Uh oh, now riscv64 is building buildah as well 2024-02-25 02:38:22 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 s/was// 2024-02-25 02:38:49 s/failure// 2024-02-25 02:38:51 Whatever 2024-02-25 02:46:04 Hmm, buildah built on riscv64 2024-02-25 02:50:09 algitbot: retry master 2024-02-25 02:51:25 algitbot: retry master 2024-02-25 02:52:42 algitbot: retry master 2024-02-25 02:53:56 algitbot: retry master 2024-02-25 02:55:08 algitbot: retry master 2024-02-25 02:56:18 algitbot: retry master 2024-02-25 02:57:34 algitbot: retry master 2024-02-25 02:58:49 algitbot: retry master 2024-02-25 11:43:49 should we disable buildah on ppc64le for now? 2024-02-25 11:44:19 fine with me 2024-02-25 12:10:12 sorry for the spam :/ 2024-02-25 12:16:30 algitbot: retry master 2024-02-25 14:17:58 !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 fix that, meaning stop buildah from building its own ginkgo (and go-md2man, and golangci-lint) 2024-02-25 14:19:54 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 but it seems only go-md2man is actually needed to build the man pages 2024-02-25 14:40:53 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 Sorry, !61262 2024-02-25 14:42:05 and !55694 2024-02-25 14:56:55 Adding `#include ` solves that, so i've included it in !61274 2024-02-25 16:08:02 algitbot: retry master 2024-02-25 16:57:14 algitbot: retry master 2024-02-25 17:13:25 algitbot: retry master 2024-02-25 17:26:44 algitbot: retry master 2024-02-25 18:05:20 algitbot: retry master 2024-02-25 18:12:22 algitbot: retry master 2024-02-25 19:54:22 anoying that that zsh test is flaky 2024-02-25 23:13:35 algitbot: retry master 2024-02-26 02:42:22 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 on riscv64, that is 2024-02-26 02:43:52 s/as/has/ 2024-02-26 02:46:34 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 algitbot: retry master 2024-02-26 02:51:19 algitbot: retry master 2024-02-26 02:55:38 algitbot: retry master 2024-02-26 03:06:42 algitbot: retry master 2024-02-26 03:07:58 algitbot: retry master 2024-02-26 03:11:19 algitbot: retry master 2024-02-26 03:22:43 algitbot: retry master 2024-02-26 03:24:00 algitbot: retry master 2024-02-26 03:25:12 algitbot: retry master 2024-02-26 03:26:22 algitbot: retry master 2024-02-26 15:20:59 algitbot: retry master 2024-02-26 19:07:07 lol 2024-02-26 22:24:55 uh oh 2024-02-26 22:25:23 sigh 2024-02-26 22:25:40 why do they error on "unsupported configuration" instead of just disabling the feature 2024-02-26 22:35:13 it's just x86 and ppc64le though...??? 2024-02-27 02:42:57 ptrc: the same architectures that are in disable-moz-stackwalk.patch (that was not removed, btw, just disabled) 2024-02-27 02:43:42 ohh, i must be blind then 2024-02-27 02:43:57 also yeah i messed up a bit 2024-02-27 02:44:13 weh, i'll fix that up tomorrow-ish 2024-02-27 02:45:12 so the patch is needed after all? 2024-02-27 20:51:03 algitbot: retry master 2024-02-27 20:58:44 algitbot: kick 2024-02-27 20:58:46 a 2024-02-27 21:17:15 algitbot: retry master 2024-02-27 21:53:25 algitbot: retry master 2024-02-28 00:14:07 algitbot: retry master 2024-02-28 00:17:21 algitbot: retry master 2024-02-28 00:20:36 algitbot: retry master 2024-02-28 00:23:09 algitbot: retry master 2024-02-28 00:25:33 algitbot: retry master 2024-02-28 00:28:18 algitbot: retry master 2024-02-28 00:31:14 algitbot: retry master 2024-02-28 13:34:52 algitbot: retry master 2024-02-28 18:54:21 algitbot: retry master 2024-02-28 19:46:09 algitbot: retry master 2024-02-28 19:56:22 ikke: thank you, looks unit-python on arm is broken 2024-02-29 12:17:42 algitbot: retry master