2024-09-01 01:03:04 Bouncer fail led to replay of old messages, sorry 2024-09-01 05:22:18 looks like libadwaita is due to mesa not supporting orcjit, but there is mesa 24.2 coming out which has orcjit 2024-09-01 05:22:27 so maybe we just go to mesa 24.2 git snapshot? 2024-09-01 05:25:43 There is a mesa MR: !70830 2024-09-01 05:26:07 But when i tried that, it didn't fix the tests 2024-09-01 05:27:23 Same test issue affects (at least) !71153, !68002 2024-09-01 06:13:49 i tried that but i get "unsupported relocation type 14" and cannot determine what that is 2024-09-01 06:18:11 R_LARCH_TLS_DESC64 2024-09-01 06:20:42 should be pretty straightforward to teach musl to handle these, other archs already have them 2024-09-01 06:51:35 workaround for now: add -mtls-dialect=trad to default CFLAGS when building on loongarch 2024-09-01 07:11:18 cool 2024-09-01 07:11:19 ok 2024-09-01 07:11:47 i have confirmed that upgrade mesa to 24.2.1 fixes the libadwaita and other builds 2024-09-01 07:21:29 for libshumate, the checks can be re-enabled for loongarch64 and riscv64 after mesa is upgraded? 2024-09-01 07:21:48 or only loongarch64? 2024-09-01 07:26:22 probably both. the issue with mesa is OrcJIT, which is only supported in the new mesa. 2024-09-01 07:26:58 though at the moment, the mesa 24.2.1 build is broken for some targets on riscv64, but 70830 fixes it with the GCC fix I just landed 2024-09-01 07:33:00 cool. will check back on libshumate when mesa upgrade is merged 2024-09-01 08:39:16 upgrade is a no-go because of riscv64 but looking into getting the relocation type issue alone fixed in mesa, at least that should allow the tests to pass without llvmpipe 2024-09-01 08:42:38 if my current mesa build passes libadwaita tests i will push that instead for now until we can get riscv64 unblocked for mesa 2024-09-02 02:13:58 The builder is currently building community/datovka, which produced a 445.1G log file the last time it ran 2024-09-02 03:29:42 It's been a long time, datovka is still being built 2024-09-02 03:30:35 ikke:Thanks 2024-09-02 03:34:22 Yes, datovka very likely isn't going to pass 2024-09-02 03:34:40 Hopefully, the log won't be bigger than last time 2024-09-02 03:41:44 I now try to build datovka locally 2024-09-02 03:42:16 Wondering why there is such a large log file 2024-09-02 07:27:29 I think i've broke GCC on ppc64le (while trying to fix it, ironically), sorry about that 2024-09-02 07:27:53 It should be fixed with a pkgrel bump, which i am hoping to do together with enabling GDC for Loongarch 2024-09-02 07:28:30 So, riscv64 doesn't have to do two 8-hours builds of GCC 2024-09-02 07:52:15 I failed to build 'community/datovka' on x86_64 and loongarch64. 2024-09-02 07:52:52 Error messages are same. 2024-09-02 07:53:33 cely:That's ok, you already know how to fix it 2024-09-02 07:53:53 I also build datovaka==4.23.7(a lower version), also failed. 2024-09-02 09:27:29 znley: can you update the MR for openjdk11? 2024-09-02 09:27:39 you mention we can remove that option? 2024-09-02 09:44:31 I have updated. 2024-09-02 09:45:05 Added two options, can only remove one. 2024-09-02 11:04:11 https://tpaste.us/yYVg 2024-09-02 11:04:44 this is the problem with datovka 2024-09-02 11:05:10 -rw-r--r-- 1 buildoze buildoze 955.9G Sep 2 10:58 /var/cache/distfiles/buildlogs/build-edge-loongarch64/community/datovka/datovka-4.23.8-r0.log 2024-09-02 15:25:25 https://tpaste.us/YYQw current build failures on community 2024-09-03 06:19:22 Regarding the error “LLVM ERROR: Relocation type not implemented yet!”, do we need to disable checks for loongarch64 and riscv64 first, or continue waiting for !70830 ? 2024-09-03 07:52:15 For !71345, try https://files.pythonhosted.org/packages/source/j/jaraco_text/jaraco_text-$pkgver.tar.gz instead 2024-09-03 07:53:44 as we usually don't prefer the URL with the checksum 2024-09-03 07:54:12 Going AFK, bye 2024-09-03 07:58:01 cely: done,thanks 2024-09-03 14:07:28 would be good if we could get !70830 fixed. I'm trying to bisect it now 2024-09-03 14:38:21 looks like it was a fix for loongarch that broke riscv64 build: This MR introduced the regression for riscv64: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30599 2024-09-04 03:45:11 So, GCC Gnat successfully builds testing/gprbuild 2024-09-04 03:47:38 Will update the patch so if anyone needs it in the future, they can get it bootstrapped (i probably won't be pushing for this, at least for now, as it seems gprbuild is the only aport needing Gnat) 2024-09-04 06:04:09 cely:Yeah, thank you anyway:) 2024-09-04 06:06:22 Does anyone know what's going on !71321. 2024-09-04 06:06:39 It passed on my pc. 2024-09-04 06:06:56 But all pipelines failed. 2024-09-04 06:13:38 Somehow, i remembered main/yash 2024-09-04 06:14:46 I mean, it just popped into my mind 2024-09-04 06:14:51 Try removing the sticky bit 2024-09-04 06:15:03 setgid bit* 2024-09-04 06:16:29 Quite a number of packages in main/ are affected, iirc 2024-09-04 06:18:18 However, usually the CI is okay, and it's the builders that have that set, causing things to fail 2024-09-04 06:45:11 I'll be going AFK, bye 2024-09-04 06:47:37 Bye 2024-09-04 06:53:52 what does build-edge-tmp-loongarch64, and we have build-edge-loongarch64 2024-09-04 06:54:29 I guess there are two for good reason but don't know what does second one 2024-09-04 07:18:09 Currently, build-edge-tmp-loongarch64 is still in the transitional stage. It has built complete packages for all repos. The packages built here will be uploaded to dev.a.o/edge and provided to gitlab CI for use 2024-09-04 07:18:14 When the official builder(build-edge-loongarch64) has finished all 3 repos (that is, the packages of the 3 repos are uploaded to dl-cdn), it may be considered to be offline 2024-09-04 07:18:23 So now build-edge-loongarch64 is still in the community, and there will be testing later, so we also need to keep build-edge-tmp-loongarch64 2024-09-04 07:24:21 thank you for explanation 2024-09-04 07:25:42 You're welcome 2024-09-04 11:48:57 mio: mesa 24.2.1 has been merged, and !67997 is now passing, so you can try re-enabling rv64 and loongarch on !71153 2024-09-04 12:42:34 cely: thanks 2024-09-04 12:47:18 You're welcome 2024-09-04 12:47:59 If anyone finds any other MR blocked by tests failing due to mesa, feel free to mention it here 2024-09-04 12:48:23 I've rebased !68002, and will get it in when CI is green 2024-09-04 15:23:41 Hmm, the aports enabled in community/ went from 6031 to 6030, so i went looking for the aport that just got disabled, and it is: ima-evm-utils (!71313) 2024-09-04 15:24:29 Anyway, 1020 aports left to build in community :) 2024-09-04 16:23:13 We will very likely be able to reach < 1000 aports left soon 2024-09-04 16:32:00 we are less than 1000 \o/ 2024-09-04 16:33:36 995 aports left :) 2024-09-05 01:10:44 Nice, now there are 940:) 2024-09-06 02:07:21 652 now 2024-09-06 02:48:29 Yeah, thanks for fixing some more aports 2024-09-06 03:13:59 i tried to update !71507 and loongarch passed, but upstream introduced an overflow bug on 32-bit architecture :( 2024-09-06 03:16:47 Maybe the libc crate can just be updated to at least 0.2.155 2024-09-06 03:59:58 I hope i didn't enable some problematic LDC tests that passes in the CI, but not on the builders 2024-09-06 04:00:07 pass* 2024-09-06 04:05:24 Ok...at least Loongarch finally moved on to Dub (DLang's package manager) 2024-09-06 04:06:56 Hmm, 1814 tests ran, in CI it was 1818 2024-09-06 04:07:44 and the tests only took 45 seconds, so most of the (extra, compared to CI) time was spent building 2024-09-06 04:14:06 Dub took 7 minutes in CI, i think the tmp builder taking longer may be due to Dub fetching packages to build 2024-09-06 04:14:37 Ok, now it's done :) 2024-09-06 04:15:01 x86_64 on the other hand...probably got hit by some long running tests 2024-09-06 04:15:34 As there's a difference in the number of tests ran in CI and on the builder, i think that may be the issue 2024-09-06 04:17:10 Oh wait, hmm, just rechecked, and it is 1814 tests for Loongarch on the CI too 2024-09-06 04:17:25 1818 was from a previous run, with more tests enabled 2024-09-06 04:18:16 x86_64 very likely has more tests enabled though 2024-09-06 04:24:02 For reference, a successful build of community/ldc on x86_64 in CI: https://gitlab.alpinelinux.org/Celeste/aports/-/jobs/1506408 2024-09-06 04:25:32 1822 tests ran, and it took just 20 seconds 2024-09-06 04:25:52 So, not sure what's going on with the builder 2024-09-06 05:54:18 Now it looks like everything is built successfully 2024-09-06 05:55:42 Yes :) 2024-09-06 14:36:16 Almost reaching 500 aports left to build 2024-09-06 15:57:25 It seems Loongarch has 1 failing test for SDL2 (testautomation): !71540 2024-09-06 15:57:36 I'll rerun CI in case the test is just flaky 2024-09-07 01:05:30 cely: It seems that CI still fails now 2024-09-07 01:07:02 Yeah, so that's something you all can look into 2024-09-07 01:08:39 Ok,sure 2024-09-07 01:21:26 I built sdl2 2.30.7 locally and all tests passed, I am using dl-cdn.a.o/alpine/edge/main and dev.a.o/edge/community/ 2024-09-07 01:24:32 Hmm, ok, i guess it will be up to SDL2's maintainer then what to do about this 2024-09-07 01:28:59 I updated comment in MR 2024-09-07 01:36:06 Ok, thanks 2024-09-07 02:04:02 Does anyone remember which aports reported R_LARCH_TLS_DESC64 related errors on loongarch64? 2024-09-07 02:04:55 mesa 2024-09-07 02:04:56 As GCC now TLS descriptors on loongarch64, I don't think I can find them easily 2024-09-07 02:05:59 Is it mesa you're thinking about? 2024-09-07 02:06:17 Also, there's now !71529 2024-09-07 02:06:47 So, maybe mesa won't be built with GCC anymore soon 2024-09-07 02:11:33 I tried to build mesa 24.2.1 with gcc-14.2.0-r1, but it did not report this error 2024-09-07 02:11:58 I now have a musl TLSDESC patch that I want to verify 2024-09-07 02:14:15 It happens when running tests 2024-09-07 02:14:30 for libadwaita or libshumate, or more likely, both 2024-09-07 02:17:54 Ok, thanks 2024-09-07 17:51:58 error in libnids-1.26-r1 might be loongarch64 specific, can't reproduce the issue on x86_64 http://build.alpinelinux.org/buildlogs/build-edge-loongarch64/community/libnids/libnids-1.26-r1.log 2024-09-08 05:05:25 needs update_config_sub 2024-09-08 05:11:28 https://git.alpinelinux.org/aports/tree/community/libnids/APKBUILD#n17 ? or like https://github.com/MITRECND/libnids/pull/12/files ? 2024-09-08 05:11:54 lol nvm 2024-09-08 05:12:02 thanks for handling that 2024-09-09 06:58:17 cely: I got "aports-openjdk8-corretto/community/openjdk8-corretto/pkg/openjdk8-corretto/usr/lib/jvm/java-1.8-openjdk/jre/lib/jfr.jar': No such file or directory" when build openjdk8-corretto. 2024-09-09 06:58:49 This happend at ">>> openjdk8-corretto-jre-lib*: Running split function jrelib..." 2024-09-09 07:03:47 Ok 2024-09-09 07:06:36 This is very likely due to using amove with an absolute path 2024-09-09 07:07:06 $_java_home begins with /, so the `*` is expanded wrongly 2024-09-09 07:07:38 I think this should be solved by changing the two instance of `*.jar` in jrelib() to `\*.jar` 2024-09-09 07:08:22 I add '--disable-jfr' for configuration according community/openjdk8, but it didn't solve. 2024-09-09 07:09:42 No, this issue happens after package() when the subpackages are built 2024-09-09 07:09:59 So, try changing escaping `*.jar` to `\*.jar` 2024-09-09 07:10:59 Ok, Magical amove. 2024-09-09 07:11:00 It is expanding *.jar to jfr.jar from the host compiler due to $_java_home beginning with /, this is one of the problems with using amove with an absolute path 2024-09-09 07:11:50 (if the absolute path exists, globs are expanded wrongly) 2024-09-09 07:13:32 Thanks, this solved it, I knew very little about abuild. 2024-09-09 07:15:03 You're welcome 2024-09-09 07:25:21 This is just a shell thing 2024-09-09 07:33:37 So, here's my findings from a weekend of trying to get openjdk8 to build 2024-09-09 07:34:49 Alpine's community/openjdk8 uses icedtea, which introduces some complications for cross-compiling, so the method that worked for openjdk17/21 doesn't work for community/openjdk8 (icedtea) 2024-09-09 07:35:10 and i think i've read somewhere that icedtea actually builds the jdk twice 2024-09-09 07:36:03 Which means openjdk8 bootstrap will probably have to involve an intermediary openjdk, and i've been looking for that, Amazon Corretto was the first to work for me 2024-09-09 07:36:56 and i've been puzzled why others can't build, in the end, it turns out that the others have build scripts that depend on some GNU sed behavior 2024-09-09 07:38:31 add GNU sed to makedepends_build, and it seems all the other JDKs start building properly, i'm currently running Adoptium Temurin through CI, and it seems to work too (but with more patches required than Corretto) 2024-09-09 07:39:44 (the other JDK versions that we have in aports do not depend on GNU sed anymore) 2024-09-09 07:41:30 With GNU sed in makedepends, i think even https://github.com/openjdk/jdk8u will work, after the correct set of patches needed has been determined 2024-09-09 07:44:11 So, my current through process is: Icedtea on x86_64 cross-compiles Corretto (or some other JDK8), then Corretto bootstraps Icedtea on Loongarch 2024-09-09 07:45:15 Going AFK now, bye 2024-09-09 09:05:34 Greet job. 2024-09-09 09:57:22 do we need openjdk8 for loongarch? 2024-09-09 10:00:31 i think we have kept openjdk8 so we didnt need to do manual bootstrap 2024-09-09 11:26:20 ncopa: We already have openjdk8 enabled for loongarch, it just hasn't been bootstrapped on the official builder 2024-09-09 11:27:07 and disabling it would mean disabling almost all of the Java aports 2024-09-09 11:48:42 aha 2024-09-09 16:33:38 cely: afaik there are patches for GCC 6 that make it support loongarch and risc-v? 2024-09-09 16:33:54 if so we can use gcj to bootstrap openjdk8 2024-09-09 17:44:13 You will have to ask Jingyun about GCC 6, i don't know about it, sorry 2024-09-09 17:44:58 Even if GCC 6 works on Loongarch, are we sure gcj will be able to boostrap the version of openjdk8 we currently have? 2024-09-09 17:45:43 I have already spent a lot of time on Corretto, and i think it should work 2024-09-09 17:46:53 If anyone else has some time to spare, instead of looking into gcj from an old GCC, maybe find out why openjdk8 cannot be cross-compiled now 2024-09-09 17:46:58 It was done before 2024-09-09 17:47:28 but apparently no one is able to get it to work again 2024-09-09 17:51:49 (and yes, this is very likely partly due to the fact that when the first bootstrap was done, we were not aware that it would have to be done again, otherwise more details records would've been kept) 2024-09-09 17:52:34 s/details/detailed/ 2024-09-09 18:38:24 we bootstrapped with gcc6 2024-09-09 18:38:38 gcc6 -> gcj -> ecj -> openjdk7 -> openjdk8 2024-09-10 00:14:36 The original openjdk8 of loongarch64 was enabled by me, but I compiled it manually. 2024-09-10 00:15:52 The compilation process was quite difficult, and it was not even completed in the end, only a certain stage of compilation was completed. 2024-09-10 00:16:52 Then I used this unfinished openjdk8 to successfully native build on loongarch64. 2024-09-10 00:17:26 This is where the first version came from, but it actually didn't work for bootstrap. 2024-09-10 00:29:08 If the GCJ bootstrap path has to involve JDK7, then i think that's a big roadblock itself 2024-09-10 00:30:07 Even if we could find the required GCC 6 patches to get it to work on Loongarch, and then in turn got GCJ and ECJ working, JDK7 has no support for Loongarch, as far as i know 2024-09-10 00:38:39 I also think this introduces too much complexity。 2024-09-10 00:43:26 Either keep openjdk8 of loongarch64 non-bootable, or consider using openjdk8-corretto instead of openjdk8. 2024-09-10 00:57:43 I agree with cely, we are already working on openjdk8-corretto and this can make openjdk8 work properly 2024-09-10 01:03:33 Ariadne: We do not have patches for GCC 6, upstream support for loongarch64 since GCC 12 2024-09-10 01:04:05 (i'm talking about openjdk in alpine to begin with) 2024-09-10 01:07:43 Oh, So the original openjdk in alpine was bootstrapped with gcc6 2024-09-10 04:59:53 I just found out something, it seems s390x and 32-bit arm* are also using zero variant for openjdk8, it seems icedtea does that for you, without you having to specify --with-jvm-variants (community/openjdk11/17/21 has this) 2024-09-10 05:23:59 So, that is probably the deeper meaning behind "oracle dropped support for 32 bit" 2024-09-10 05:24:29 and people wonder why other distros are still able to package 32-bit JDKs :) 2024-09-10 05:28:30 Very likely the situation is similar to that of GHC, where i think i've seen other distros build it in "unregisterised" mode just to enable it on more archs (s390x being one of them, iirc) 2024-09-10 05:35:20 and this also answers why some archs took more than 6 hours to build community/abcl, all those are on zero variant (i switched to using openjdk11 for s390x back then, and now i know it is because jdk11 is where s390x got support for server variant) 2024-09-10 05:42:19 The speed difference is really apparent, what takes server variant 15 minutes or less to complete, will take more than an hour on zero variant 2024-09-10 05:47:26 Looking around icedtea's $builddir, i see openjdk.build-boot and openjdk.build directories, so that probably means icedtea builds openjdk in 2 stages 2024-09-10 05:48:04 and the file list seems to be the same 2024-09-10 06:58:06 Thanks cely, openjdk8-corretto has been built successfully on tmp builder 2024-09-10 06:58:12 It would be great if someone could cross-build an openjdk8-corretto bootstrap for the official loongarch64 builder 2024-09-10 13:06:38 99 aports left to build :) 2024-09-10 15:05:52 toss one down, spin it around 2024-09-10 15:42:57 ... 99 aports left on the wall 2024-09-10 15:43:23 That does not sound like progress 2024-09-10 15:43:29 :P 2024-09-10 15:44:03 lol it actually happened for a short while yesterday at the 110 mark, went back up to 112 briefly 2024-09-10 15:45:36 that said, there are a few more MRs in the queue so it should come back down again later 2024-09-10 15:46:46 It's now in 86 btw 2024-09-10 15:48:24 maybe we could get it to 80 or 75 today 2024-09-10 15:51:48 If anyone wants to try openjdk8 bootstrap, this is the command i used: `EXTRADEPENDS_BUILD="build-base-loongarch64" EXTRADEPENDS_TARGET="libgcc libstdc++-dev musl-dev" CHOST=loongarch64 BOOTSTRAP=bootimage abuild -r` 2024-09-10 15:51:59 Probably it will work even without BOOTSTRAP set 2024-09-10 15:53:29 Packages i have in ~/packages were probably leftover from running the normal bootstrap.sh, and also https://gitlab.alpinelinux.org/Celeste/aports/-/commits/try-openjdk-bootstraps 2024-09-10 15:54:45 What znley and i tried was cross-compiling openjdk8-corretto first, and then using that to build community/openjdk8 (which is now disabled for Loongarch) 2024-09-10 15:55:56 That's because openjdk8 uses icedtea, which builds jdk8 in 2 stages, and i think one of the stages is failing when cross-compiled (znley tried it, but i didn't) 2024-09-10 16:01:27 After openjdk8-corretto is available, community/openjdk8 can be re-enabled, and it should build itself with corretto without needing any further interaction 2024-09-10 16:06:40 I don't have time now, but which package needs to be bootstrapped like that? 2024-09-10 16:06:56 community/openjdk8-corretto 2024-09-10 16:07:03 right 2024-09-10 16:07:38 But right now it will fail because openjdk8-bootstrap is not available? 2024-09-10 16:07:53 Yes 2024-09-10 16:08:36 So should we remove that from the makedepends then? 2024-09-10 16:08:44 openjdk8-corretto provides openjdk8-bootstrap, and it will be able to bootstrap itself 2024-09-10 16:09:26 abuild -r will try to install openjdk8-bootstrap, which does not exist 2024-09-10 16:10:01 I think you might be looking at community/openjdk8 2024-09-10 16:10:12 openjdk8-corretto has the -bootstrap package in makedepends_build 2024-09-10 16:11:21 I had the correct one open, but I don't cross-compile that often, so forgot the implications of makedepends_build 2024-09-10 16:12:49 A complicating factor to cross-compiling openjdk is that it needs all those X11/cups/alsa libs in sysroot, which are not built by the normal bootstrap.sh, the bootstrap.sh in my "try-openjdk-bootstraps" branch does though, but i didn't tidy that up specifically for openjdk8-corretto 2024-09-10 16:13:27 I think clandmeter was just installing them from the main/ repository, instead of bootstrapping everything from scratch 2024-09-10 16:14:38 I haven't confirmed this, but corretto should depend only on packages in main/ (community/openjdk8 depends on other things in community/ like gtk+2.0) 2024-09-10 16:56:09 I'll be going AFK, bye 2024-09-10 17:18:58 bye! 2024-09-11 00:11:40 morning 2024-09-11 00:19:34 hello! 2024-09-11 00:23:20 builder made it to 75 aports left 2024-09-11 01:09:53 71 aports left 2024-09-11 01:36:21 yes ... waiting for a few more aports to come through (package maintainer approval) 2024-09-11 01:37:59 it's good though, was hoping to reach 75 today and it's past that 2024-09-11 01:38:32 thanks to all the people reporting, fixing and merging 2024-09-11 01:41:56 !71321 seems to fail only on CI 2024-09-11 04:41:34 I'm now trying https://gitlab.alpinelinux.org/Celeste/aports/-/commits/try-openjdk8-bootstrap 2024-09-11 04:42:11 So far, util-linux has failed to build, and alsa-lib and libxcb tried to link to /usr/lib/libgcc_s.so.1 (from the host architecture) 2024-09-11 04:43:12 They use libtool, so maybe something is going on there, or maybe this has to do with the /usr merge 2024-09-11 04:45:10 As for util-linux, i've just removed it from bootstrap.sh for now, i don't remember what required it, but the build log for main/fontconfig just scrolled by 2024-09-11 04:45:21 and util-linux-dev is there, but it's in makedepends_build 2024-09-11 04:45:36 In my branch, that is 2024-09-11 04:46:00 and now a third package (libwebp) has tried to link to /usr/lib/libgcc_s.so.1 2024-09-11 04:50:11 Maybe something else needs to be installed into sysroot, libgcc already is 2024-09-11 04:58:22 Ok, libsm needs util-linux-dev, and libsm in turn is needed by libxt 2024-09-11 05:01:11 util-linux tries to link to /usr/lib/libncursesw.so from host architecture 2024-09-11 05:22:17 Oh well, since there are problems with using bootstrap.sh from scratch, perhaps i could just provide the bootstrap openjdk8-corretto, since i am abuild to build it from what i have built before 2024-09-11 05:52:55 Anyway, my changes have been pushed to "try-openjdk8-bootstrap" (this is a new rebased branch, compared to yesterday's "try-openjdk-bootstraps") 2024-09-11 05:54:04 I'm keeping the old branch as the diff between the 2 probably contains the answer to why alsa-lib, libxcb, and libwebp failed to build due to libtool trying to link against host libgcc_s.so 2024-09-11 05:54:44 or maybe my setup just got messed up, or i tried different archs between then and now 2024-09-11 06:38:28 Tried to cross-compile openjdk8-corretto to riscv64 and armv7 with the changes in "try-openjdk8-bootstrap", and it builds 2024-09-11 06:38:51 I'm seeing the libtool-libgcc_s issue on armv7, but not riscv64, which is able to skip the incompatible /usr/lib/libgcc_s.so.1 2024-09-11 06:50:44 So, this means that cross-build openjdk8-corretto for all arches is now successful 2024-09-11 07:07:49 I didn't really try all 2024-09-11 07:08:26 Just tried Loongarch again, and the incompatible /usr/lib/libgcc_s.so.1 is also skipped, so this is probably an issue with 32-bit, where it can't skip the incompatible libgcc and tries to use it 2024-09-11 07:09:37 OK 2024-09-11 07:09:45 Thanks 2024-09-11 07:10:57 So, running `./bootstrap loongarch64` with the "try-openjdk8-bootstrap" branch should result in a working openjdk8-corretto for Loongarch, and bootstrap.sh can be edited to remove openjdk11/17/21 from the packages list, or the build process just stopped after jdk8 2024-09-11 07:11:22 ./bootstrap.sh* 2024-09-11 07:17:34 very nice 2024-09-11 07:21:27 So you have also cross-built openjdk8-corretto-*.apk for loongarch64 2024-09-11 07:21:42 If we temporarily install these apk packages to the official builder, and use them to build openjdk8-corretto and openjdk8 locally, this will not require anyone to cross-build again, and can solve some of the builder blocking 2024-09-11 09:28:16 clandmeter did you bootstrap the other openjdk packages? 2024-09-11 09:54:17 ncopa: Yeah, clandmeter has cross-built openjdk 11/17/21 bootstrap before 2024-09-11 09:58:05 clandmeter: do you have time to help with openjdk8? 2024-09-11 10:34:03 he is on holydays/vacation I think 2024-09-11 10:35:07 or some other 'task', didn't contacted me for about 7 days which is unusual 2024-09-11 10:44:32 I can work on it after work 2024-09-11 14:17:29 i can work on it next week, but not now 2024-09-11 19:17:34 cely: Am I supposed to run bootstrap.sh first? 2024-09-11 19:17:51 I get a bunch of errors when trying to run the command you provided 2024-09-11 20:11:11 loongarch builder apparently can access xkbcommon.org, so it can't build libxkbcommon 2024-09-11 20:12:28 Ermine: link? 2024-09-11 20:12:44 nevermind, I've restarted the job and it went ok 2024-09-11 20:13:58 this one tho: https://gitlab.alpinelinux.org/Ermine/aports/-/jobs/1514202 2024-09-11 20:20:12 I don't expect anything being blocked on those 2024-09-12 00:47:56 ikke: With the "try-openjdk8-bootstrap" branch, it's just run bootstrap.sh 2024-09-12 00:48:51 You'll probably want to edit it as it will build openjdk11/17/21 as well 2024-09-12 05:06:16 How was !57351 handled? 2024-09-12 05:07:21 If i'm reading the comment correctly, Simon provided a bootstrap openjdk21 that he cross-compiled locally 2024-09-12 05:08:48 right 2024-09-12 06:36:14 ikke: do you have time to help with openjdk8-corretto bootstrap? thanks 2024-09-12 06:37:03 In my afternoon 2024-09-12 06:38:08 Ok, that's great, thank you 2024-09-12 06:41:52 To prevent any confusion, the branch i tried (and it was working) was: https://gitlab.alpinelinux.org/Celeste/aports/-/commits/try-openjdk8-bootstrap 2024-09-12 06:42:29 and the command i used was `./bootstrap.sh loongarch64` 2024-09-12 06:50:02 Ok, thanks. When I ran that command on the master branch, it complained about $CBUILDROOT not being set for loongarch64 2024-09-12 06:53:33 From openjdk8-corretto or one of its dependencies? 2024-09-12 06:54:48 The changes needed for openjdk8-corretto itself are in master, but its dependencies aren't, there are about 30 of them, and i modified them in one sitting 2024-09-12 06:56:05 If bootstrap.sh becomes the preferred way of bootstrapping OpenJDKs, i'll see if i can find time to tidy up my work, but there are 2 or 3 aports using meson that i just couldn't get to work, so i went back to using ./configure 2024-09-12 07:06:08 cely: the bootstrap script itself 2024-09-12 07:06:54 I think I understand why 2024-09-12 07:07:37 You have an older abuild that doesn't recognize loongarch? 2024-09-12 07:09:28 I thought of using qemu-user to run OpenJDK on Loongarch, but i need to find which arch has the faster emulated JVM 2024-09-12 07:09:55 Apparently, emulated x86_64 is faster than aarch64, but still not really fast enough 2024-09-12 07:12:18 It needs to be cross-compiled from a different starting arch 2024-09-12 07:15:57 Yeah, you tried it on Loongarch? 2024-09-12 07:17:12 😶 2024-09-12 07:19:29 😀 2024-09-12 07:21:28 That’s the idea of bootstrap, to have a cross compiler. 2024-09-12 07:22:36 but to cross compile Java via bootstrap.sh it’s easier to have the builders repo in sysroot repofile. 2024-09-12 07:23:03 else you will get into a dependency hell 2024-09-12 07:34:47 hm, 3A6000 could be good desktop machine 2024-09-12 07:35:25 just need few kernel tweaks 2024-09-12 07:36:00 especially if kernel 6.12 get PREEMT_RT 2024-09-12 07:36:23 It had a pretty slow console for me. Not sure what was wrong 2024-09-12 07:36:53 what is slow? 2024-09-12 07:38:37 Scrolling 2024-09-12 07:39:24 like connecting to a remove serial console 2024-09-12 07:39:25 yes, it is not fast but I hope it will be better with 6.12 2024-09-12 07:39:33 remote* 2024-09-12 07:39:51 but with X it is fine 2024-09-12 07:40:13 it must be some setting 2024-09-12 07:40:29 but yes. in general its a nice system. 2024-09-12 07:40:32 maybe some tweaks for radeon card 2024-09-12 07:40:46 i think the onboard is similar 2024-09-12 07:40:52 I will test its internal video card 2024-09-12 07:41:14 next week though, when 6.11 will be released 2024-09-12 07:41:20 ones ssh was running i disconnected the screen 2024-09-12 07:42:18 I didn't had time to work previous days on it, wasted time on kernel for bananapi f3 2024-09-12 07:43:19 but on weekend I will try to prepare loongarch64 flavor for linux-edge 2024-09-12 07:45:02 not sure should I base config on riscv64 or aarch64 2024-09-12 07:45:35 probably on both 2024-09-12 07:47:14 looks like lts is not based on any of them, maybe ppc 2024-09-12 07:47:59 right, but I mean about kernel config 2024-09-12 07:48:17 x86* and aarch64 are considerable larger compared to loongarch 2024-09-12 07:48:31 yes thats what im refering to 2024-09-12 07:49:13 it is RISC so I think it is closer to riscv and ppc64 2024-09-12 07:49:55 hope it doesn't have 'speculative' execution :-) 2024-09-12 07:49:57 i dont think the major size difference is arch related? 2024-09-12 07:50:55 yes, but all of them have their 'special' add-ons, usually 2024-09-12 07:52:49 instruction decoders, "execution path" (hardware), and address 'model' 2024-09-12 07:53:46 though I still didn't read much about this base for loongarch 2024-09-12 07:54:13 there are probably a lot more drivers and such enabled for the major arches 2024-09-12 07:54:39 I think so, but loongarch devs are active 2024-09-12 07:59:37 anyway, I'm pleased with machine 2024-09-12 08:00:21 hm s/pleased/satisfied/ 2024-09-12 08:00:58 huajingyun: thank you :-) 2024-09-12 08:09:11 mps: You're welcome, glad you're satisfied with machine;-) 2024-09-12 08:09:20 It's great that you are also going to enable loongarch64 for linux-edge, thanks 2024-09-12 08:09:53 np, pleasure will be mine (as they say) 2024-09-12 08:10:11 also forgot to say thank you to clandmeter 2024-09-12 08:10:27 you are awesome 2024-09-12 08:11:11 you both 2024-09-12 08:18:35 Yeah,thanks clandmeter:) 2024-09-12 11:22:35 running bootstrap.sh now 2024-09-12 11:47:31 Has it encountered any issues so far? 2024-09-12 11:51:28 Hmm, so far expart fetch failed 2024-09-12 11:51:31 expat 2024-09-12 11:51:50 sourceforge is not cooporating 2024-09-12 11:56:38 ikke: if you set DISTFILES_MIRROR to https://distfiles.alpinelinux.org/distfiles/edge? 2024-09-12 12:01:49 huajingyun: It's working already 2024-09-12 12:01:55 And finished 2024-09-12 12:02:08 >> openjdk8-corretto: Updating the community/loongarch64 repository index... 2024-09-12 12:03:10 That is good! 2024-09-12 12:04:01 So now the goal is to use that package to provide openjdk8-bootstrap on the builder, right? 2024-09-12 12:06:09 I think the usual process is this cross-compile package is manually installed, openjdk8-corretto is rebuilt natively, then this cross-compiled package is uninstalled 2024-09-12 12:06:29 right 2024-09-12 12:06:39 makes sense 2024-09-12 12:19:14 building openjdk8-corretto now on the builder 2024-09-12 12:24:28 After that, the builder should be able to do it's own thing, right? 2024-09-12 12:24:48 Then there is a native openjdk8-bootstrap provider and it can build everything else? 2024-09-12 12:25:11 Yes 2024-09-12 12:25:41 After the cross-compiled bootstrap aport is removed, there should be no further manual interaction needed 2024-09-12 12:26:48 cely: Then may also need to re-enable community/openjdk8 for loongarch 2024-09-12 12:27:17 Yes, but maybe tomorrow for that 2024-09-12 12:27:27 The native build will take a while 2024-09-12 12:27:50 and community/openjdk8 (icedtea) will take twice as long due to building the JDK in 2 stages 2024-09-12 12:28:15 Yes, it is 2024-09-12 12:29:00 I wonder why we are even sticking with icedtea anyway, probably that was needed during the initial bootstrap gcj -> ecj -> icedtea7 -> icedtea8 process, but not it seems a bit outdated 2024-09-12 12:29:08 s/not/now/ 2024-09-12 12:32:25 As in, building in 2 stages may have made sense back then, but that may be redundant now 2024-09-12 12:40:08 Maybe you can open an issue on gitlab 2024-09-12 12:41:34 There is no replacement yet though, as Corretto crashes on x86 2024-09-12 12:44:09 and switching to Zero variant would mean long compile times, as you've probably noticed now, the difference between how fast the cross-compilation takes, and how slow it is natively 2024-09-12 13:35:43 Still building 2024-09-12 13:36:15 It takes about 1.5 hours 2024-09-12 13:38:24 Server variant (and cross-compiling from x86_64) takes less than 10 minutes 2024-09-12 13:44:05 Anyway, it should hopefully be finishing soon 2024-09-12 13:44:10 Thanks for bootstrapping it 2024-09-12 13:53:26 It's finished 2024-09-12 13:53:43 starting the builder again 2024-09-12 13:58:10 \o/ 2024-09-12 13:58:37 cely: thank you as well for doing all the work to make this possible 2024-09-12 14:00:38 You're welcome 2024-09-12 14:04:25 I've also taken into consideration the next stable bootstrap process, and have tried to make sure that things can be bootstrapped uniformly, as in you only need to bootstrap one and the same aport for all archs, which is community/openjdk8, all the other providers will take care of themself 2024-09-12 14:05:41 but i am aware that no cross-compilation is involved then, and the bootstrap aport is just installed from edge 2024-09-13 01:19:19 40 aports left to build :) 2024-09-13 10:15:44 firefox is not enabled on loongarch64, anyone knows anything about this 2024-09-13 10:19:00 oh, '/work/aports/community/firefox-esr/src/firefox-115.14.0/ipc/chromium/src/build/build_config.h:133:4: error: Please add support for your architecture in build/build_config.h' 2024-09-13 10:19:29 so chromium must be supported also iiuc 2024-09-13 10:19:57 didn't know that firefox depends on chromium 2024-09-13 10:20:39 (why then it is separate browser I wonder) 2024-09-13 11:55:50 nice news for loongarch64 and kernel 6.12 https://lore.kernel.org/lkml/20240913085812.1030686-1-chenhuacai@loongson.cn/ 2024-09-13 13:54:49 ohm, I didn't noticed that setserial have a problem to build with gcc 14, sorry. thanks for fixing it ncopa 2024-09-13 16:05:43 reposting this for visibility #16448 2024-09-13 16:21:15 (in case anyone might be interested in debugging the issue) 2024-09-13 16:23:20 odd, that just went by the builders 2024-09-13 16:23:36 seems to only happen in ci? 2024-09-13 22:55:23 mps: i started working on it a while back, but there is a mess of rust dependencies that need to be bumped 2024-09-13 23:00:44 mio: SIGILL almost always means fortify violation, so it is most likely code which is overrunning buffer 2024-09-13 23:05:14 okay, thanks. why does it only manifest in loongarch64? 2024-09-13 23:06:30 not sure. if it's only on loongarch, it could be memory alignment related 2024-09-13 23:06:50 i would run the testcase manually 2024-09-13 23:06:56