2024-08-01 01:44:31 algitbot: retry master 2024-08-01 02:57:05 algitbot: retry master 2024-08-01 10:27:21 cely: now it's swi-prolog 2024-08-01 12:15:46 Tried swi-prolog in CI and it passes on x86: https://gitlab.alpinelinux.org/Celeste/aports/-/jobs/1470028 2024-08-01 12:16:20 So i'm not sure what's up 2024-08-01 12:16:29 Left over files on the builders maybe? 2024-08-01 12:20:46 algitbot: retry master 2024-08-01 12:23:23 jaq will need a patch for Rust 1.80.0 2024-08-01 12:23:26 Let me see if upstream has it 2024-08-01 12:24:38 Hehe 2024-08-01 12:25:04 Upstream replaced the offending crate instead of updating it: https://github.com/01mf02/jaq/pull/199 2024-08-01 12:25:37 "Apart from the fact that I do not like packages stopping to build when updating the compiler, updating time to 0.3.36 would require raising MSRV to 1.67 which I do not like." 2024-08-01 12:25:39 :D 2024-08-01 12:26:05 what is MSRV? 2024-08-01 12:26:23 Minimum Supported Rust Version 2024-08-01 12:27:17 ah 2024-08-01 12:28:07 Haha, and a comment on that PR: "Why do you need an MSRV that is more than 18 months old?" 2024-08-01 12:28:32 "Got 1 illegal states 2024-08-01 12:28:34 " 2024-08-01 12:28:48 No idea how files on the builder would affect that 2024-08-01 12:29:22 an now it passed? 2024-08-01 12:29:28 oh no, testing 2024-08-01 12:30:22 There's an upgrade for jaq, i guess i'll just use that 2024-08-01 12:46:30 swi-prolog building again 2024-08-01 12:47:18 and it's built successfully this time 2024-08-01 12:47:42 🙃 2024-08-01 12:48:19 The builders love playing illegal instructions with us 2024-08-01 12:53:17 Oh no 2024-08-01 12:53:33 fetch failed 2024-08-01 12:53:37 algitbot: retry master 2024-08-01 13:03:47 algitbot: retry master 2024-08-01 14:36:28 algitbot: retry master 2024-08-01 14:43:29 algitbot: retry master 2024-08-01 15:23:34 algitbot: retry master 2024-08-01 15:27:31 algitbot: retry master 2024-08-01 15:32:46 algitbot: retry master 2024-08-01 20:24:53 ptrc: thanks 2024-08-02 00:57:18 Hi, I am checking !69990. 2024-08-02 04:33:19 algitbot: retry master 2024-08-02 04:54:54 I think rakudo on armhf needs to be killed and restarted 2024-08-02 05:06:43 algitbot: retry master 2024-08-02 05:08:04 Thanks 2024-08-02 05:08:54 It hung on tests, as i expected 2024-08-02 05:09:26 yes 2024-08-02 05:36:52 and now it passed🤷 2024-08-02 05:47:29 :) 2024-08-02 08:49:56 algitbot: retry master 2024-08-02 15:32:19 Here we go 2024-08-02 15:57:52 I wonder if some cert used in py3-moto tests expired 2024-08-02 15:59:07 Hmm, or maybe it's some other cert verification error 2024-08-02 16:02:58 is there an efficient way to check if one's packages might be affected/fail to build with new gcc? 2024-08-02 16:03:28 Not really 2024-08-02 16:03:33 or is it expected that no action will be required from maintainers for the most part? 2024-08-02 16:03:40 Maybe check Debian's bug tracker 2024-08-02 16:04:39 okay, cheers ^^ 2024-08-02 16:05:19 mio: https://udd.debian.org/bugs/?release=trixie&ftbfs=only&merged=ign&fnewerval=7&flastmodval=7&rc=1&sortby=id&sorto=asc&format=html#results has a list that begins around the middle of the page 2024-08-02 16:06:15 great, thanks 2024-08-02 16:06:31 but not everything will apply to us (i tried clisp and dillo from aports, and they pass) 2024-08-02 16:07:11 So, maybe scroll through and see if anything stand out to you, and then try building it from aports to see if we're affected too 2024-08-02 16:10:03 We will need all the help we can get to hopefully deal with a big portion of GCC 14 issues before the 3.21 builders come online (and start rebuilding main/ and community/) 2024-08-02 16:11:42 okay! seeing a few familiar pkgnames, will pull latest edge and try rebuilds 2024-08-02 16:12:05 Great, thanks :) 2024-08-02 17:07:11 I wonder if riscv64 has gotten stuck on python3 2024-08-02 17:07:24 From CI, i know gcc14 will take around 7 hours on riscv64 2024-08-02 17:08:08 Hmm, last Python run on riscv64 took almost 2 hours 2024-08-02 18:26:12 cheese confimed to have some issue, not seeing any report in upstream repo about it yet. looking to see if has been patched elsewhere 2024-08-02 18:28:50 not a major package anyway, will check others in the meantime 2024-08-02 18:30:20 algitbot: retry master 2024-08-02 18:48:19 are the affected packages in alpine being tracked in an issue/ticket somewhere? brasero, freerdp appear to have failed as well 2024-08-02 18:52:45 No, they'll show up whenever they are built again in CI 2024-08-02 18:55:06 mio: but feel free to make tickets for packages you know are broken 2024-08-02 18:56:53 okay. wasn't sure if putting them through ci as drafts would help mark them or only clog the queue with broken bits 2024-08-02 18:57:36 adding them somewhere to dedupe check efforts 2024-08-02 19:08:03 #16335 2024-08-02 20:56:19 huh, connection closed prematurely 2024-08-02 20:58:20 algitbot: retry master 2024-08-03 03:01:35 Oh riscv64 finally finished GCC 2024-08-03 03:26:21 algitbot: retry master 2024-08-03 04:30:14 I wonder if we should find a way to allow sbcl to bootstrap itself 2024-08-03 04:30:37 That would be ideal if possible 2024-08-03 04:30:47 Otherwise it's about half an hour (which would be more than halved) every month 2024-08-03 04:31:07 and only bootstrap it from ecl when creating a new Alpine stable release 2024-08-03 04:31:24 s/would/could/ 2024-08-03 04:32:04 Probably both ecl and sbcl (maybe ccl too, but ccl is x86_64-only) would have to provide "sbcl-bootstrap" 2024-08-03 04:32:14 with differing provider_priorities 2024-08-03 04:33:21 we'd also need a -stage0 package 2024-08-03 04:34:27 When would that come into the picture? 2024-08-03 04:34:50 That's the package that can be built without depending on itself 2024-08-03 04:35:04 It then provides -bootstrap 2024-08-03 04:35:24 Hmm 2024-08-03 04:35:36 after stage0 is built, the actual package can be built with a higher priority -bootstrap 2024-08-03 04:35:48 (it's a scheme nmeum came up with) 2024-08-03 04:35:48 Can't ecl providing "sbcl-bootstrap" at a lower priority be sort of a stage0? 2024-08-03 04:35:57 if that works 2024-08-03 04:36:07 then yes 2024-08-03 04:37:30 Well, perhaps a stage0 would work too, and the stage0 doesn't need to be updated monthly 2024-08-03 04:39:31 I wonder if we have the stage0 scheme documented anywhere.. 2024-08-03 04:39:46 probably in some comment 2024-08-03 04:40:39 Hehe, or commit message 2024-08-03 04:42:56 nmeum's idea is basically to be explicit in how we bootstrap each package instead of carrying it through through numerous releases 2024-08-03 04:43:18 (with sometimes unknown / forgotten origin) 2024-08-03 04:44:15 Carrying it through numerous releases would be like Rust and OpenJDK? 2024-08-03 04:44:30 and gcc :) 2024-08-03 04:44:39 but yes 2024-08-03 04:45:06 Ok 2024-08-03 04:46:25 Probably the stage0 package can also install its executables in some place other than $PATH, so aports don't accidentally pick up the bootstrap compilers if they're not promptly removed from the builders 2024-08-03 04:47:01 stage0 is not installed manually 2024-08-03 04:47:22 that's the whole idea, it can be built without manual intervention 2024-08-03 04:47:30 Hmm 2024-08-03 04:47:32 Ok 2024-08-03 04:47:37 we had that with go for a while 2024-08-03 04:47:55 I've seen some stage0's (like fpc, i think) that use upstream's binaries 2024-08-03 04:48:02 dotnet, cabal 2024-08-03 04:48:07 I guess we don't really want to encourage that, right? 2024-08-03 04:48:16 Even for stage0's 2024-08-03 04:48:27 https://pkgs.alpinelinux.org/packages?name=*-stage0&branch=edge&repo=&arch=x86_64&maintainer= 2024-08-03 04:48:43 cely: encourage what exactly? 2024-08-03 04:49:04 Using not built-from-source stage0's 2024-08-03 04:49:54 testing/fpc-stage0 is an example, i think 2024-08-03 04:50:08 well, it's about being honest what the origin is. If we cannot bootstrap it from source, let's make it clear how it is bootstrapped 2024-08-03 04:50:10 or have i overlooked something, and most stage0's are not built from source? 2024-08-03 04:51:09 so ofcourse, we prefer things to be built from source if possible, but for many projects, that's ot feasible 2024-08-03 04:51:45 For rust it would probably mean to compile some early version and then painstakingly build each subsequent release 2024-08-03 04:51:46 Ok 2024-08-03 04:52:06 :) 2024-08-03 04:54:27 I will look into sbcl-stage0 when i find the time, i think sbcl doesn't have that only-previous-version-can-build-current-version thing like Rust 2024-08-03 04:54:49 So, a stage0 that's updated, say, every 3 months would be nice 2024-08-03 04:56:28 and from what i see now, a stage0 can help avoid adding providers in other packages 2024-08-03 06:00:41 Thanks :) 2024-08-03 06:00:44 I was just looking into it 2024-08-03 06:05:53 ldapvi and lua-sql failed for me on main, in case you're already looking into it 2024-08-03 06:06:12 heimdal failed, but probably unrelated reason 2024-08-03 14:58:22 algitbot: retry master 2024-08-03 14:58:41 algitbot: retry 3.20-stable 2024-08-03 17:16:51 algitbot: retry master 2024-08-04 00:59:06 algitbot: retry master 2024-08-04 02:22:20 algitbot: retry master 2024-08-04 03:41:41 algitbot: retry master 2024-08-04 04:44:21 Stupid typo, lol 2024-08-04 05:39:49 fetch failed 2024-08-04 05:39:52 algitbot: retry master 2024-08-04 05:40:47 algitbot: retry master 2024-08-04 06:03:17 fetch failed 2024-08-04 06:03:19 algitbot: retry master 2024-08-04 13:18:06 cely: thanks 2024-08-04 13:19:11 ACTION checks..ah, cheese 2024-08-04 13:19:14 You're welcome 2024-08-04 13:28:01 ^^ 2024-08-04 14:35:12 algitbot: retry master 2024-08-04 14:50:36 algitbot: retry master 2024-08-04 15:08:07 algitbot: retry master 2024-08-04 15:59:16 algitbot: retry master 2024-08-04 16:47:20 algitbot: retry master 2024-08-04 16:54:14 algitbot: retry master 2024-08-05 02:59:33 I wonder if algitbot mentioned anything else failing on riscv64, besides ceph18 and starship 2024-08-05 05:24:41 algitbot: retry master 2024-08-05 05:41:01 gnome-boxes is known to fail with gcc 14, so not sure if that is related 2024-08-05 05:41:29 the MR was sent in 5 days ago, before gcc 14 was pushed if recalled correctly 2024-08-05 05:42:26 if riscv64 got new gcc in the meantime, that might be an issue 2024-08-05 05:43:56 Yes it did 2024-08-05 05:45:12 "retry master" will start from main/, so the first "retry master" (after a build failed on riscv64) after gcc14 was merged would get riscv64 to build that 2024-08-05 05:46:38 okay 2024-08-05 14:56:51 main/cgdb fails to build now, can't seem to find readline. not sure yet if gcc-related 2024-08-05 14:58:56 or at least something changed since last commit in 2024-03-12 2024-08-05 15:25:15 algitbot: retry master 2024-08-05 16:06:01 algitbot: retry master 2024-08-05 16:18:49 I think Jingyun was still waiting for musl upstream to accept the binutils-related patch before opening an MR for it 2024-08-05 16:20:06 I wonder how many aports are affected, and if this means the Loongarch builder will now be blocked 2024-08-05 20:47:56 got the number of packages that still do `python3 setup.py` down to 256 ^^ 2024-08-05 20:52:04 whoops 2024-08-05 20:52:18 > test_issue_certificate[ap-southeast-1-aws] 2024-08-05 20:52:20 what the 2024-08-05 21:30:45 algitbot: retry master 2024-08-05 21:41:48 algitbot: retry master 2024-08-05 21:55:49 algitbot: retry master 2024-08-06 00:02:55 odd, ci failed to find judy-dev but pkgs.a.o shows it exists? 2024-08-06 00:07:54 the package could be fetched when building locally 2024-08-06 05:22:42 Why is efs-utils taking so long on riscv64 :/ 2024-08-06 05:22:52 Hopefully it is not going to fail as wlel 2024-08-06 05:22:55 well* 2024-08-06 05:24:07 Ok, it takes about 7 minutes in CI 2024-08-06 05:24:42 Done, so riscv64 is finally uploading community/ 2024-08-06 05:29:00 151 aports to build in testing/ 2024-08-06 12:12:03 go fast break stuff 2024-08-06 14:04:10 algitbot: retry master 2024-08-06 14:10:33 algitbot: retry master 2024-08-06 14:11:27 algitbot: retry master 2024-08-06 14:11:44 algitbot: retry master 2024-08-06 14:12:20 algitbot: retry master 2024-08-06 14:13:16 algitbot: retry master 2024-08-06 14:14:10 algitbot: retry master 2024-08-06 14:52:28 algitbot: retry master 2024-08-06 15:04:46 algitbot: retry master 2024-08-06 15:05:48 algitbot: retry master 2024-08-06 15:09:43 algitbot: retry master 2024-08-06 15:19:46 algitbot: retry master 2024-08-06 16:03:53 algitbot: retry master 2024-08-07 01:52:08 riscv64 has finally uploaded all the packages it didn't build due to being down \o/ 2024-08-07 02:56:07 \o/ 2024-08-07 10:40:53 algitbot: retry master 2024-08-07 10:53:25 algitbot: retry master 2024-08-07 13:45:08 down to 116, got a lot of very annoying cases where tests were already failing before the switch 2024-08-07 15:41:32 algitbot: retry master 2024-08-07 15:43:58 andypost[m]: are you okay with judy being potentially moved to main? it's needed by newer version of zmap 2024-08-07 15:44:33 mio: yep 2024-08-07 15:44:51 cool, thanks ^^ 2024-08-07 21:39:22 algitbot: retry master 2024-08-08 02:47:44 are you fucking kiddingme 2024-08-08 02:47:51 thanks ARM 2024-08-08 02:47:56 never taking another patch from them 2024-08-08 02:53:52 oh 2024-08-08 02:53:58 this may be GCC 14 issue 2024-08-08 03:00:57 ... 2024-08-08 03:01:07 well it sure is good i have acquired one of these machines i guess 2024-08-08 08:50:31 algitbot: retry master 2024-08-08 09:56:09 algitbot: retry master 2024-08-08 14:54:45 uh-oh, probably should have checked with cely before unmarking task3 2024-08-08 14:55:58 thought some rust issue in loongarch64 mentioned the other day was fixed 2024-08-08 14:58:58 it passed in ci though, sorry about that 2024-08-08 14:59:04 What do i know? 2024-08-08 14:59:07 Haha 2024-08-08 14:59:15 I probably wouldn't have caught that as well 2024-08-08 14:59:24 curious why it passed in CI then 2024-08-08 14:59:29 ^^" sorry, might have messed up something 2024-08-08 15:00:15 yeah, not sure. it initially failed with the same error as ppc64le, then passed after the ring patch was refreshed 2024-08-08 15:00:42 I think it is failing tests 2024-08-08 15:01:11 Yes, 29 tests fail 2024-08-08 15:02:25 odd, the tests should have hard failed in ci 2024-08-08 15:02:54 had to disable tests for arm* as those did fail 2024-08-08 15:03:27 Any idea if the tests require network access? 2024-08-08 15:04:10 not sure, can check logs 2024-08-08 15:06:25 maybe an upgrade test, would have to check the source to be sure 2024-08-08 15:10:34 ah, not upgrade, that is a task upgrade, not app upgrade 2024-08-08 15:19:11 is there a way to do the opposite of options="net" or like cargo fetch --offline flag, to disable network in the test block and see if any tests fail as a result? 2024-08-08 15:21:08 Maybe try `abuild rootbld`? 2024-08-08 15:22:12 option=net is exactly to allow network during rootbld 2024-08-08 15:22:21 so removing it and using rootbld indeed 2024-08-08 15:22:52 thanks 2024-08-08 15:44:47 not seeing any tests that require network access 2024-08-08 15:45:47 at least from grepping the test suite, trying to also check with `abuild rootbld` 2024-08-08 16:27:29 will it be okay to temporarily disable tests for loongarch64 in the meantime, to not block the builders? 2024-08-08 16:29:00 some of the tests already fail on arm* and 1 on x86, might reach out to upstream about those 2024-08-08 17:31:28 none of the 12 tests that failed require network access as fas as could tell 2024-08-08 17:34:48 But no clue as to why they actual fail? 2024-08-08 17:36:36 not at the moment 2024-08-08 17:37:58 one of the tests was a bit inconsistent (failed once on s390x but passes on re-run, previously passed twice), so it could be a mix of flaky test and something arch-specific 2024-08-08 17:38:38 if it needed net access, would the same tests not fail across the board? 2024-08-08 17:39:10 well, the builders are not actively blocking network atm, but the loongarch builders network is less than optimal 2024-08-08 17:46:47 ah, it managed to get all the rust packages to build, if it is pinging somewhere inaccessible haven't found it yet 2024-08-08 17:53:27 the search continues, but didn't want to disrupt the builders in the meantime 2024-08-08 18:58:46 ikke: thanks 2024-08-08 23:09:29 algitbot: retry master 2024-08-09 01:40:05 Hmm, now to think about it, only after main/ is uploaded do the builder upgrade to the new packages built (including this new musl) 2024-08-09 01:40:16 algitbot: retry master 2024-08-09 04:23:34 algitbot: retry master 2024-08-09 05:11:13 algitbot: retry master 2024-08-09 05:37:22 algitbot: retry master 2024-08-11 17:39:45 algitbot: retry master 2024-08-11 19:42:12 algitbot: retry master 2024-08-11 22:08:18 algitbot: retry master 2024-08-11 22:35:57 oh-no 2024-08-11 22:39:18 cc65 built in CI a week ago 2024-08-11 22:50:37 !70420 2024-08-11 22:51:02 could work 2024-08-12 00:19:15 nope 2024-08-12 00:31:12 cc65 looks like ftbfs gcc 14 2024-08-12 00:31:31 s/ftbfs/ftbfs with/ 2024-08-12 00:35:19 I hope Daniel Hejduk or someone will look into that, I just didn't want to leave the builders stuck 2024-08-12 00:35:42 algitbot: retry master 2024-08-12 00:39:57 algitbot: retry master 2024-08-12 00:40:37 upstream applied flag to disable the error https://github.com/cc65/cc65/issues/2460 2024-08-12 00:41:00 that said, seems the preference is to have the errors fixed if possible 2024-08-12 00:55:17 algitbot: retry master 2024-08-12 00:58:15 algitbot: retry master 2024-08-12 01:01:11 ehlo 2024-08-12 01:17:53 Hi omni 2024-08-12 01:18:23 how are you? 2024-08-12 01:21:40 I'm alright, been busy these few days with GHC (and now Rust), so haven't been watching MRs so closely (which could a good thing) 2024-08-12 01:26:32 oh, ghc 2024-08-12 01:28:54 Too bad it seems to take more than 16 hours to build on loongarch64 and ppc64le 2024-08-12 01:29:22 That's in CI, not sure if the builders will be faster, probably not 2024-08-12 01:30:09 it builds on those? 2024-08-12 01:32:20 for some reason I thought it wouldn't build for other architectures than what we build for 2024-08-12 01:32:27 gtg 2024-08-12 01:32:30 ttyl 2024-08-12 01:34:27 Bye 2024-08-12 01:34:58 It does build, but needs some tricks :) 2024-08-12 01:35:49 Not sure if they should be enabled though, i probably don't want to add something that will take so long to build 2024-08-12 01:36:15 Not to mention that the CI timeout for alpine/aports is just 6 hours, so it will not succeed there 2024-08-12 07:41:37 good exercise, still 2024-08-12 08:31:53 finger crossings 2024-08-12 08:56:30 algitbot: retry master 2024-08-12 11:58:04 algitbot: retry master 2024-08-12 12:00:08 algitbot: retry master 2024-08-12 12:11:29 algitbot: retry master 2024-08-13 14:48:30 algitbot: retry master 2024-08-13 15:17:58 algitbot: retry master 2024-08-13 15:26:00 algitbot: retry master 2024-08-13 15:26:02 algitbot: retry master 2024-08-13 16:11:48 algitbot: retry master 2024-08-13 16:17:43 algitbot: retry master 2024-08-13 16:20:46 algitbot: retry master 2024-08-13 16:24:12 algitbot: retry master 2024-08-13 20:24:07 just finished a cursory pass through main. caveats: x86_64 only, didn't build packages like kernels, perl, rust etc. which are already being rebuilt recently or regularly. ~51 packages had a gcc rebuild error (including ones n c o p a added and a few reported by others). another dozen or so had various other errors (failed tests, curl fetch issues) 2024-08-13 20:27:41 had an error with a few perl packages, `ERROR: perl-test-simple-1.302200-r0: trying to overwrite usr/share/perl5/vendor_perl/Test2/AsyncSubtest.pm owned by perl-test2-suite-0.000163-r1.` not sure if an issue with my installation or something else 2024-08-13 20:31:18 seems not bad out of 1.5k packages 2024-08-13 20:33:30 haven't decided yet how best to check the larger community repo 2024-08-13 23:15:36 mio: is it related to #16335 2024-08-13 23:36:38 andypost[m]: the perl ones? 2024-08-13 23:37:07 maybe 2024-08-13 23:39:37 don't know, perl-test-simple was updated recently, was guessing it might have something to do with it 2024-08-13 23:41:09 #16361 is for a grab bag of other packages that failed rebuilds 2024-08-13 23:42:31 was going to test one of the perl packages on another vm to see if the same error occurs 2024-08-13 23:59:36 it's occurring in another vm, will add them in the other not-gcc ticket for now 2024-08-14 01:14:48 mio: Unfortunately, i've had less time this past week, and no longer watch Gitlab as closely as i used to do anymore 2024-08-14 01:18:23 celie: no worries, hope all is well 2024-08-14 20:07:56 algitbot: retry master 2024-08-14 20:16:18 algitbot: retry master 2024-08-14 20:21:20 algitbot: retry master 2024-08-14 20:30:06 algitbot: retry master 2024-08-14 21:21:33 algitbot: retry master 2024-08-14 21:32:14 algitbot: retry master 2024-08-14 22:17:44 algitbot: retry master 2024-08-14 22:20:16 algitbot: retry master 2024-08-14 22:42:28 algitbot: retry master 2024-08-14 23:03:47 algitbot: retry master 2024-08-14 23:06:19 algitbot: retry master 2024-08-14 23:12:38 algitbot: retry master 2024-08-14 23:15:45 algitbot: retry master 2024-08-14 23:20:56 algitbot: retry master 2024-08-14 23:25:08 algitbot: retry master 2024-08-15 01:27:36 omni: xen build error may be gcc 14 issue, -Wimplicit-function-declaration become errors by default now 2024-08-15 01:27:58 whereas was warning before 2024-08-15 01:30:23 the older version had a similar error 2024-08-15 01:32:23 The Xen error has been noted in #16106 2024-08-15 01:36:35 yeah, probably not a problem before if it was a warning? 2024-08-15 01:40:36 Yes, now it's an error in GCC 14 2024-08-15 03:15:11 Interesting, rexml outputs some part of its build log into MQTT 2024-08-15 03:15:42 main/ruby-rexml, on build-edge-loongarch64 2024-08-15 03:16:10 Hmm, now ruby-rss is doing the same 2024-08-15 03:16:45 I wonder what those 2 aports do differently that causes part of their build log to be sent over MQTT 2024-08-15 03:17:08 Perhaps it is the file descriptor that they output on 2024-08-15 03:28:40 Hmm, ruby-racc also did the same thing earlier on 2024-08-15 04:11:36 Now ruby-minitest just outputted its build log on build.a.o 2024-08-15 04:17:34 Ok...why does cargo-auditable fail to build 2024-08-15 04:17:37 on Loongarch 2024-08-15 04:17:50 too bad build logs aren't uploaded yet 2024-08-15 05:25:50 ruby-debug also outputted its build log onto MQTT, and main/space seems to have outputted its test log 2024-08-15 07:44:13 algitbot: retry master 2024-08-15 10:38:52 algitbot: retry master 2024-08-15 14:04:46 algitbot: retry master 2024-08-15 14:40:25 algitbot: retry master 2024-08-15 14:53:43 algitbot: retry master 2024-08-15 16:14:41 algitbot: retry master 2024-08-15 16:16:57 algitbot: retry master 2024-08-15 16:22:29 algitbot: retry master 2024-08-15 16:22:40 algitbot: retry master 2024-08-15 16:23:27 algitbot: retry master 2024-08-15 16:35:16 algitbot: retry master 2024-08-15 16:36:39 if only riscv64 could build kcodecs 6.5.0... 2024-08-15 16:36:55 algitbot: retry master 2024-08-15 16:38:29 algitbot: retry master 2024-08-15 16:39:15 oh, I see, it's disabled on riscv64 2024-08-15 16:43:17 let's see if !70574 2024-08-15 22:04:29 algitbot: retry master 2024-08-15 22:22:25 algitbot: retry master 2024-08-16 05:01:25 sea of red 2024-08-16 05:40:19 PureTryOut: https://lists.debian.org/debian-arm/2024/08/msg00038.html mentions that ktexttemplate happens with -O2 2024-08-16 05:41:19 (test failure on aarch64) 2024-08-16 14:31:32 algitbot: retry master 2024-08-16 14:42:39 algitbot: retry master 2024-08-16 14:43:40 algitbot: retry master 2024-08-16 14:45:01 algitbot: retry master 2024-08-16 14:53:21 algitbot: retry master 2024-08-16 15:21:53 algitbot: retry master 2024-08-16 15:27:13 algitbot: retry master 2024-08-16 17:45:42 algitbot: retry master 2024-08-16 17:49:08 algitbot: retry master 2024-08-16 17:52:43 PureTryOut: can you look at elisa and ktexttemplate? 2024-08-16 17:53:06 if you read ~7 minutes back you see I tried fixing ktexttemplate 2024-08-16 17:53:15 sorry, missed that 2024-08-16 17:53:35 the timing 😜 2024-08-16 17:53:58 did you saw my message regarding that test failure, or did you find it yourself? 2024-08-16 17:54:05 I saw your message 2024-08-16 17:54:09 ok, cool 2024-08-16 17:56:49 it... seems to have worked? 2024-08-16 17:57:08 or I suppose it tries other packages first 2024-08-16 17:57:20 yes, it built main first, and 2 packages in community 2024-08-16 18:03:39 building elisa now 2024-08-16 18:05:18 algitbot: retry master 2024-08-16 18:05:35 again elisa :/ 2024-08-16 18:06:28 well yeah, expected. I didn't touch it yet 2024-08-16 18:06:34 No clue why that one test only fails there though 2024-08-16 18:06:37 algitbot: retry master 2024-08-16 18:06:49 damn it do ktexttemplate first algitbot 😢 2024-08-16 18:06:55 Yeah, that's what I meant 2024-08-16 18:06:59 oh whatever, I'll just disable that test 2024-08-16 18:11:00 ikke: btw I'm working on getting Alpine/musl CI upstream, already have KDE Discover running on it to test the apk backend (which is now also upstream!) 2024-08-16 18:11:20 cool 2024-08-16 18:11:54 oof 2024-08-16 18:12:06