2024-08-01 02:39:28 apk-tools builds with the GCC 14.2.0 release candidate :) 2024-08-01 03:02:55 Is GCC 14.2 released today? I am waiting 2024-08-01 03:11:25 First failure of the day: gpm needs #include in old_main.c 2024-08-01 03:11:57 That was the schedule, but very likely later on 2024-08-01 03:16:33 Second failure of the day: an -Wimplicit-int error in xmlto 2024-08-01 03:18:07 has a report at Debian: https://bugs.debian.org/1075673 2024-08-01 03:24:49 Solved with xmlto 0.0.29, but source tarball is at a different location, and it has no configure script, so needs autoreconf 2024-08-01 03:38:06 Ok, it seems that GCC upgrade does cause some problems, this may be just part of it 2024-08-01 03:38:11 Many packages can only be found by rebuilding 2024-08-01 03:44:51 I have a spare machine, maybe I'll try compiling them on it too(I guess !69862 will not be merged so quickly, a few arches failed) 2024-08-01 03:44:52 Yes 2024-08-01 03:49:18 Hehe 2024-08-01 03:49:22 That is not the criteria 2024-08-01 03:49:50 I have fixed those archs, just waiting for the 14.2.0 release to push the fix together with it 2024-08-01 03:50:20 I think the criteria may be more like, make sure the builder is not blocked first 2024-08-01 03:50:38 32-bit is now blocked, and hasn't uploaded for a few weeks now 2024-08-01 03:51:16 So, we probably wouldn't want to add GCC 14, and potentially have community/ blocked on that too (further increasing the upload backlog) 2024-08-01 03:52:01 Probably having GCC 14 while testing/ hasn't finished is alright, it is testing after all 2024-08-01 03:52:36 Anyway, samurai builds, sqlite builds and passes tests, now building curl and seeing if it will pass tests 2024-08-01 03:55:26 Ok, curl is good 2024-08-01 04:01:25 Now trying fltk and dillo 2024-08-01 04:14:36 Those are good 2024-08-01 04:25:09 Now trying perl 2024-08-01 04:38:29 Hmm, i'm getting some errors: "PL_current_context: TLS definition in /tmp/ccnaBPOA.ltrans0.ltrans.o section .tbss mismatches non-TLS reference in /tmp/ccnaBPOA.ltrans1.ltrans.o", "/tmp/ccnaBPOA.ltrans1.ltrans.o: error adding symbols: bad value" 2024-08-01 04:38:37 I guess i have to go rebuild musl 2024-08-01 04:44:55 Hmm, that didn't do the trick, maybe it's due to me having another version of Perl installed 2024-08-01 05:55:49 Now trying busybox 2024-08-01 06:40:09 Now trying cmake 2024-08-01 06:49:07 Ok,I'm looking at perl 2024-08-01 06:51:30 Thanks :) 2024-08-01 08:11:31 cely:The perl error is caused by binutils-2.42, and binutils upstream has fixed, see: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=029e52bac7f3a6dd8b39f7f3d298b73174da806b 2024-08-01 08:11:37 It looks like upstream plans to release 2.43 next week: https://sourceware.org/pipermail/binutils/2024-July/135853.html 2024-08-01 08:12:01 Maybe we can upgrade it after 2.43 is released:) 2024-08-01 08:14:04 huajingyun: I don't have time to look more at it but I agree it should be upgraded 2024-08-01 08:14:50 also, thanks cely for your effort for gcc 2024-08-01 08:15:01 You're welcome 2024-08-01 08:15:28 Hopefully it can be merged soon so everyone can get involved in fixing the issues it brings 2024-08-01 08:15:38 cely: are you also celie 2024-08-01 08:15:44 Yes 2024-08-01 08:15:58 hm, why two nick, I wonder 2024-08-01 08:16:10 Yes, agree:) 2024-08-01 08:16:49 Actually more than two, i guess i just haven't gotten around to set up a bouncer or something 2024-08-01 08:17:14 ah ok (but confusing) 2024-08-01 12:34:30 Seems like new sbctl (!69968) has a Go module that's having some issues on Loongarch 2024-08-01 12:35:23 Hmm, and it's a module used for tests 2024-08-01 13:08:38 znley: i have made some changes to !69990, so please pull those changes first if you're going to push to that branch again 2024-08-01 13:09:00 Hmm, znley is not here? 2024-08-01 13:09:39 timed out a couple of hours before 2024-08-01 13:09:56 Sorry, I can only check it tomorrow morning (sbctl) 2024-08-01 13:10:34 No problem 2024-08-01 13:11:06 Relay the message to znley please 2024-08-01 13:11:27 That MR passes on other archs now, will fix lint, and then run the Loongarch CI 2024-08-01 13:11:30 Ok, sure 2024-08-01 13:11:33 I'll be going AFK now 2024-08-01 13:11:36 o/ 2024-08-01 13:11:39 Bye 2024-08-01 14:51:10 Updated my MR for GCC 14.2.0, CI has passed on x86* and arm* 2024-08-01 14:51:23 Probably riscv64 will take too long and time out again 2024-08-01 18:47:58 sbctl build fails. loongarch64 needs to be added here: https://github.com/microsoft/ms-tpm-20-ref/blob/e9fc7b89d865536c46deb63f9c7d0121a3ded49c/TPMCmd/tpm/include/LibSupport.h#L46 2024-08-01 18:48:56 but I think its sort of stupid, instead of listing every single known 64 bit system they should probably just detect the word size, by looking at ULONG_MAX or similar 2024-08-01 18:49:12 yeah, indeed 2024-08-01 18:50:32 im disabling loongarch64 for now, to unblock the buidler 2024-08-01 18:51:14 any idea why it kept rebuilding the package? is '-k' provided? 2024-08-02 00:57:38 Hi, I am checking !69990. 2024-08-02 01:01:46 cely: I submitted them all as one commit, and it failed. Can it be passed by splitting it into two submit? 2024-08-02 01:02:25 The changes to rust lock are great. 2024-08-02 01:23:48 sbctl fails. In addition to the link mentioned by ncopa, we should also give priority to adding loongarch64 in https://github.com/google/go-tpm-tools/blob/655a2a10acf499a20ca771ebc10d15f6b819e583/simulator/ms-tpm-20-ref/TPMCmd/tpm/include/LibSupport.h#L4 2024-08-02 01:23:54 Since ncopa has disabled it temporarily, I'll prioritize submitting the fix upstream (go-tpm-tools and ms-tpm-20-ref) 2024-08-02 01:27:13 znley: Your original commit failed on the CI because py3-pydantic-core failed tests 2024-08-02 01:27:48 and py3-pydantic then failed because it was using the old py3-pydantic-core 2024-08-02 01:28:10 py3-pydantic-core needs py3-tzdata in checkdepends 2024-08-02 01:30:41 I see, my system has py3-tzdata pre-installed. 2024-08-02 01:36:14 Ok 2024-08-02 01:42:19 Actually now looking at it, sbctl also has tests disabled for ppc64le and s390x 2024-08-02 01:44:08 (it was probably the same test that failed on Loongarch) 2024-08-02 01:47:34 It looks like it is, the comment mentions "# not supported by github.com/google/go-tpm-tools/simulator" 2024-08-02 01:48:36 and those were caught by the CI 2024-08-02 10:13:39 looks like gcc 14.x will be needed for 3.21 stable 2024-08-02 11:49:16 i am about to merge gcc14 2024-08-02 11:57:45 huajingyun: thank you for following it up with upstream 2024-08-02 11:58:14 does loongarch64 support secureboot? 2024-08-03 01:27:49 ncopa: No, secureboot is not supported 2024-08-03 02:07:05 Hmm, now that GCC 14.2.0 has been merged, i think it may be time to update the CI image used for Loongarch 2024-08-03 02:07:37 Otherwise it will upgrade GCC 14.2.0 every time the CI runs, which takes some time 2024-08-03 02:08:46 One of my aports has been stuck at upgrading GCC for about 50 minutes now 2024-08-03 02:09:24 It's a rather simple one, and should build in under a minute 2024-08-03 02:11:02 I just created a MR to fix perl build error !70081 2024-08-03 02:17:04 cely:I will create a new minirootfs and upload it to dev.a.o/~loongarch/ later, but it may require ikke to update CI image 2024-08-03 02:25:35 Thanks 2024-08-03 02:39:43 You're welcome 2024-08-03 02:56:08 cely: updated 2024-08-03 02:57:24 huajingyun: im using my own minirootfs but didnt update it. any reason why i should? 2024-08-03 02:59:03 btw, i only updated ci on my box here 2024-08-03 03:01:01 You updated the Docker image for CI on your box, or on the other one? 2024-08-03 03:02:23 I guess you meant you updated it on your box, and the minirootfs is referring to something else 2024-08-03 03:04:34 clandmeter: Your CI network should be fine, I want to update minirootfs, just guessing that the CI on the Chinese machine may be slow due to the upgrade of gcc 2024-08-03 03:05:38 ah ok 2024-08-03 03:05:42 well its updated anyways 2024-08-03 03:05:56 so we gain another few seconds :) 2024-08-03 03:06:16 Hehe 2024-08-03 03:06:51 I'm looking at the latest Rust beta from last week.. 2024-08-03 03:07:03 and it seems they vendored yet more ancient copies of the libc crate 2024-08-03 03:07:03 we have an official mirror in asia 2024-08-03 03:07:08 the pkgs would be better hosted on it 2024-08-03 03:07:17 but are the Loongarch packages on it? 2024-08-03 03:07:27 I think they're only on dev.a.o for now 2024-08-03 03:07:35 yes they are 2024-08-03 03:07:46 Ok 2024-08-03 03:07:46 well they should really be on cdn 2024-08-03 03:07:52 which would fix most of the delays 2024-08-03 03:08:21 lets hope the eu boxes come online next week 2024-08-03 03:08:33 all components should be there 2024-08-03 03:08:50 will ping midasi 2024-08-03 03:08:59 So, the Rust beta has 9 vendored copies of libc...spanning 0.2.94 to the latest 0.2.155, i wonder why the Rust devs do this :/ 2024-08-03 03:22:42 For reference, Rust 1.80.0 has 5 copies of libc, but the oldest is 0.2.140 2024-08-03 03:23:53 Some really funny things happen with Rust :) 2024-08-03 03:24:06 clandmeter:I pinged midasi before but received no response 2024-08-03 03:27:20 cely: so many libc, means in rust 1.81? 2024-08-03 03:29:43 Yes 2024-08-03 03:29:59 and nightly (which will become 1.82) still maintains 9 2024-08-03 03:34:42 Well,I have always believed that we will no longer add any patches to loongarch64 starting with rust 1.81,it seems I was wrong 2024-08-03 03:38:38 Maybe you can ask your colleagues who work on Rust how the Rust host tools for Loongarch are built 2024-08-03 03:38:54 Maybe there is a way to force everything to use the latest libc 2024-08-03 03:40:00 Yes, I'm going to ask 2024-08-03 03:40:20 For the actual build, what the APKBUILD does is just: `python3 ./x.py dist --jobs ${JOBS:-2}` 2024-08-03 03:41:02 I think that should be what's used for the host tools as well, because this builds a tarball that we are then re-extracting to $pkgdir to make the .apk 2024-08-03 03:41:12 The host tools just use those tarballs, i think 2024-08-03 03:41:44 So, probably the option to force latest libc (if there is one) is an option for ./configure 2024-08-03 03:42:37 which i think can also be accomplished by editing a config.toml file 2024-08-03 04:02:24 huajingyun: fji, I can just rebuild build-base, which will make sure all packages are up-to-date 2024-08-03 04:10:01 Wow, mio is still updating the GCC 14 ftbfs issue, thanks :) 2024-08-03 04:10:34 I'm building a new build-base image for loongarch 2024-08-03 04:11:35 cely: yw ^^ that's the community list scraped from the link you provided earlier 2024-08-03 04:12:37 there are potentially more not on the list, e.g. pilot-link was a random find, it wasn't on the tracker 2024-08-03 04:12:46 working through main 2024-08-03 04:14:05 from the link, those are the ones tested failed on x86_64 2024-08-03 04:15:01 ok, docker images should be up-to-date now 2024-08-03 04:15:48 seahorse might be a bit of a problem, tried to update it a while back, it has two deps that are deprecated or replaced with a different lib upstream, and the dev mentioned in an issue they would like all features enabled across the board 2024-08-03 04:16:16 Isn't seahorse a Rust package? 2024-08-03 04:16:17 upstream being the lib dependencies 2024-08-03 04:16:26 Oh itisn't 2024-08-03 04:16:34 I must be thinking of something else 2024-08-03 04:16:45 it's an old gnome app if recalled correctly 2024-08-03 04:18:13 as it's a password manager, a bit ... not sure if it has a path forward if upstream continues to use old deps 2024-08-03 05:01:07 The Loongarch libc patch does not apply cleanly to the versions 0.2.94, 0.2.97, and 0.2.107, the other 5 copies (excluding 0.2.155 that doesn't need patching) apply successfully 2024-08-03 05:01:21 s/copies/versions/ 2024-08-03 05:01:35 I think i'll try building with those 3 versions not patched and see how things fail 2024-08-03 05:01:42 Hopefully they don't fail 2024-08-03 05:01:44 Hehehe 2024-08-03 05:02:09 but that would mean those 3 versions aren't used, so why include them in the first place 2024-08-03 05:02:25 :D 2024-08-03 05:02:34 gotta collect them all 2024-08-03 05:04:26 Thankfully they did not start collecting old LLVM versions 2024-08-03 05:23:53 lol 2024-08-03 06:01:50 ikke:That's good, thank you! and I see minirootfs also doesn't have gcc pre-installed 2024-08-03 06:01:55 I also uploaded the new minirootfs to dev.a.o/~loongarch/edge/releases/, maybe if someone wants to use it:-D 2024-08-03 06:02:06 huajingyun: yes indeed, the minirootfs is mini :P 2024-08-03 06:03:18 Yes,I remembered it wrongly 2024-08-03 06:03:43 cely:I was told that although some older libc are vendor dependencies, they are not used and from the cross-builds of rust upstream they are not used by loongarch64-linux-musl 2024-08-03 06:04:18 Ok 2024-08-03 06:56:12 huajingyun: I'm really pleased to read that secure boot is not supported 2024-08-03 06:56:50 secure boot is in 'false sense of security' camp 2024-08-03 07:44:39 mps: I haven't really researched it to be honest 2024-08-03 07:44:54 Maybe some special purpose peoples/companies would believe and require it, maybe something like commercial use, etc. I'm not sure 2024-08-03 07:46:06 huajingyun: it is enough to know 'factory' from which it is 'emerged' to know it is created for control and spying 2024-08-03 07:48:26 nice, gcc is upgraded on edge. thanks ncopa 2024-08-03 07:49:22 maybe binutils should upgraded to current development branch (ok, I know this is not good idea) 2024-08-03 07:49:30 Yes, ncopa merged yesterday 2024-08-03 07:49:50 I can remove my local build now :-) 2024-08-03 07:50:22 also thanks cely;-) 2024-08-03 07:50:48 yes, I forgot his effort, thanks cely 2024-08-03 08:01:02 hm, maybe 'her effort', sorry 2024-08-03 08:09:46 cely might want to explain "his" or "her":-D 2024-08-03 08:11:14 real name is Celeste iirc 2024-08-03 08:33:28 Maybe 2.43 will be released tomorrow https://sourceware.org/pipermail/binutils/2024-July/135853.html 2024-08-03 08:33:45 but for loongarch64, it is not the best time to upgrade binutils yet 2024-08-03 08:34:03 Because I have to update a musl patch before upgrading binutils 2.43 https://www.openwall.com/lists/musl/2024/08/02/1 (waiting for Rich's opinion and hoping for a merge) 2024-08-03 08:34:23 Or whether binutils is upgraded or not, I should also backport this patch for musl 2024-08-03 08:45:27 aha, looks good 2024-08-03 08:51:42 Yeah, so i'll follow up on this 2024-08-03 14:41:05 from the debian list as of yesterday, of the ~113 packages present in alpine, about ~58 of them appear to fail due to gcc. there a 5-6 more with different errors, they may have been already broken at some point before gcc 2024-08-03 14:42:04 the others reported pass in x86_64, a few may fail on other arches 2024-08-03 14:44:19 Thanks for working on this 2024-08-03 14:44:54 yw, thanks for the advice ^^ updated the issue with the ones that failed in x86_64 2024-08-03 14:45:08 :) 2024-08-03 14:49:53 how is your weekend? 2024-08-03 14:51:03 It's alright 2024-08-03 14:51:39 Found out that Rust 1.81 beta2 fails on a few archs 2024-08-03 14:51:57 Which reminds me, i have check if it passed for Loongarch 2024-08-03 14:52:07 Thankfully, it did 2024-08-03 14:53:18 Even with the 4 additional ancient vendored libc versions, 3 of which cannot be patched with the patch we're currently using 2024-08-03 14:57:56 good news there ^^ do they keep the older vendored version for backwards compatibility? from the scrollback it would sound like the older versions aren't used in some arches, so is it like a legacy thing? 2024-08-03 15:03:12 Maybe it's better if we don't look too deeply into this kind of craziness 2024-08-03 15:03:15 ;) 2024-08-03 15:03:58 More craziness: it seems the next version of Rust (at least the beta) will build and install its own version of LLD 2024-08-03 15:04:14 So, now it needs Ninja/Samurai to build that 2024-08-03 15:04:57 Adding lld to depends= doesn't prevent it from trying to build it itself 2024-08-03 15:05:16 Maybe there is some ./configure option i need to find out 2024-08-03 15:06:46 Added it to depends= because it will install its own version, which probably indicates that it will use it at runtime too 2024-08-03 15:08:35 It installs its own version under /usr/lib/rustlib/$CTARGET/bin/rust-lld 2024-08-03 15:09:35 Probably becuase they are patching it 2024-08-03 15:09:39 but hey, it's a beta2 (they haven't even updated stage0 to the release version of 1.80.0), hopefully they reverse some of these crazy decisions in later betas 2024-08-03 15:10:43 or maybe they don't want people to report issues to them that result from using different LLD versions 2024-08-03 15:11:08 The last time i checked, LLVM17 is still "supported" 2024-08-03 15:14:31 ^^" bundling the lld is probably not making build time any faster 2024-08-03 15:15:29 they couldn't enforce a specific lld version in another way? 2024-08-03 15:18:17 You wouldn't want them to hear of such a suggestion, otherwise they may just download it runtime ;) 2024-08-03 15:18:27 at runtime* 2024-08-03 15:18:41 lol 2024-08-03 15:18:58 Their build scripts already have the ability to download a prebuilt bootstrap compiler 2024-08-03 23:25:57 just had a look at the flagged packages and seahorse should be okay once there's a patch, got it confused with gnome-passwordsafe 2024-08-04 07:07:44 I 'fixed' aprx with adding ' -Wno-implicit-int' to CFLAGS. Not sure it is proper fix but at least it builds 2024-08-04 13:25:03 would like to know as well if that is accepted as a fix, might have seen 1-2 packages with a similar error 2024-08-04 13:26:38 not sure if setting CFLAGS is a last resort 2024-08-04 13:32:42 I think with the number of packages having issues with GCC 14, sooner or later we'll have no choice but to resort to disabling those errors 2024-08-04 13:32:58 better would be to fix source but I don't have time (and even don't have will) to do this for a lot of packages. Fixing source it job for upstream authors 2024-08-04 13:41:58 agreed ideally the errors would be fixed upstream, though would be good to know what the plan is in the meantime between waiting for fixes and some packages that have the errors all over the place (e.g. libfm) 2024-08-04 13:44:57 imo fix if possible and write report to upstream (if possible) 2024-08-04 13:45:22 else only write report to upstream 2024-08-04 13:45:41 last option is disable pkg 2024-08-04 14:55:37 I wonder if it is possible to filter CI failures by arch 2024-08-04 14:56:22 For now it the CI displays the orange exclamation mark "passed with warnings" for both lint failures and Loongarch failures 2024-08-04 14:56:28 it seems* 2024-08-04 14:58:52 Anyway, here are 2 MRs with failures that maybe you all can look into tomorrow: 2024-08-04 14:59:15 !70091 - spdk tests failed 2024-08-04 14:59:56 !70135 - seems like a Go module used is not supported 2024-08-04 15:01:04 (and additionally !70121, where CI is still running, but i doubt it will pass, as only x86_64 and aarch64 passed, all others failed, funny Rust issues again it seems) 2024-08-04 17:58:27 nice, just in time https://lists.gnu.org/archive/html/info-gnu/2024-08/msg00001.html binutils 2.43 released 2024-08-04 18:03:45 and by removing Loongarch64 patches from APKBUILD it builds fine 2024-08-04 18:08:52 to create or not create MR (17:18 ...... cely| Their build scripts already have the ability to download a prebuilt bootstrap compiler 2024-08-04 18:09:17 oh sorry, have to disable touchpad 2024-08-05 18:41:13 huajingyun: question about cracklib, just tried to upgrade it to the latest (2.10.2), and the APKBUILD fails after printing "loongarch64-alpine-linux-musl" on x86_64. if `update_config_sub` is commented out, then the build proceeds. is there a way to adjust the command so it passes? 2024-08-05 18:42:21 the line from https://git.alpinelinux.org/aports/commit/main/cracklib?id=fc95c59998285564fbcb0bfb2443898c62e10171 2024-08-05 18:43:10 sorry if it has been asked before ^^" 2024-08-05 19:52:19 `cracklib: No update needed for ./config.sub` would like to confirm whether it is still needed for loongarch64, e.g. if a change has been upstreamed 2024-08-06 00:54:16 mio:the config.sub of cracklib 2.10.2 has been updated (already supports loongarch64), so "update_config_sub is" no longer needed 2024-08-06 00:54:38 you can remove update_config_sub in APKBUILD when upgrading cracklib 2024-08-06 00:54:43 Thanks 2024-08-06 00:55:53 huajingyun: cool, thanks 2024-08-06 00:57:55 You're welcome:) 2024-08-06 01:13:21 :) 2024-08-06 01:39:56 I just checked that binutils 2.43 is still compiled successfully on builder, and there is no patch to update musl 2024-08-06 01:40:08 I found that when I verified binutils before, I used the latest code of binutils-2_43-branch branch, so it reported an error and required a patch of musl I mentioned before 2024-08-06 01:40:16 It seems that binutils 2.43 released on August 4th is not the latest commit, so it can still be compiled without this musl patch. 2024-08-06 01:41:43 Oh ok 2024-08-06 01:41:48 That's interesting 2024-08-06 01:43:05 So, the latest commit on binutils master will fail to build without the patch to musl? 2024-08-06 01:43:47 mio: update_config_sub/guess can be removed whenever abuild says so (also if you run autoreconf) 2024-08-06 01:45:00 celie:Yes,I think that's it, currently waiting for Rich to merge it 2024-08-06 01:46:30 Ok 2024-08-06 01:57:58 celie: okay. it looks like the prepare block is not needed anymore 2024-08-06 01:58:16 Wow, it seems like Tomalok did not run cargo fetch --locked for efs-utils 2024-08-06 02:00:37 thanks, also would happen to know if the ci packages are in sync with pkgs.a.o? says it can't find judy-dev but pkgs.a.o has it 2024-08-06 02:01:06 s/ci packages/ci package index/ 2024-08-06 02:04:30 Which arch are you talking about? 2024-08-06 02:05:20 loongarch64 has not yet been synced to pkgs.a.o 2024-08-06 02:07:43 I think Loongarch is not on pkgs.a.o at all 2024-08-06 02:08:05 I suspect mio may be talking about riscv64 instead 2024-08-06 02:08:17 cely: all of them 2024-08-06 02:10:43 https://pkgs.alpinelinux.org/packages?name=judy-dev&branch=edge 2024-08-06 02:12:42 Which aport can't find judy-dev in CI? 2024-08-06 02:12:52 zmap 2024-08-06 02:13:06 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/70207 2024-08-06 02:13:40 APKBUILD built locally on x86_64, pulled in judy/judy-dev 2024-08-06 02:19:21 Hmm, i don't think i've ever encountered something like that before 2024-08-06 02:20:05 Oh wait 2024-08-06 02:20:38 Actually, zmap is in main/ 2024-08-06 02:20:52 I mistakenly thought it was in community/ 2024-08-06 02:20:56 and there you have your answer 2024-08-06 02:21:17 ah! thanks 2024-08-06 02:21:18 judy is in community/ and aports in main/ cannot depend on aports in community/ 2024-08-06 02:21:51 the newer version won't build without it 2024-08-06 02:22:40 leave it or can judy be moved? 2024-08-06 02:24:37 thanks for catching that, was building locally which doesn't reinforce the dependency rule 2024-08-06 02:25:26 I think judy can be moved, as it doesn't have other dependencies in community/ (that would also need to be moved) 2024-08-06 02:25:56 So, probably you can move it in the same MR (so zmap CI succeeds), and ping @andypost about it 2024-08-06 02:27:09 great, thanks 2024-08-06 02:28:20 You're welcome 2024-08-06 03:16:58 Unfortunately, i think there is a binutils-rust problem: https://build.alpinelinux.org/buildlogs/build-edge-loongarch64/community/efs-utils/efs-utils-2.0.3-r2.log 2024-08-06 03:18:29 "BFD (GNU Binutils) 2.43 assertion fail elfnn-loongarch.c:2628" 2024-08-06 03:26:05 I tried rust-analyzer, and it fails too 2024-08-06 03:26:16 So i think Rust aports are affected (maybe all Rust aports) 2024-08-06 03:30:14 cely:I will take a look 2024-08-06 03:32:19 Thanks 2024-08-06 03:41:15 I'm now trying latest binutils-gdb master, with the musl patch you mentioned, to see if it will fix this Rust problem 2024-08-06 03:41:36 Otherwise, maybe i'll see if using Rust with lld or mold works 2024-08-06 04:14:44 No, it didn't work 2024-08-06 04:20:14 Now i'm trying to build with `unset RUSTFLAGS`, it that doesn't work, i'll probably try lld 2024-08-06 04:20:18 s/it/if/ 2024-08-06 04:35:01 Yes 2024-08-06 04:35:09 unset'ing RUSTFLAGS works 2024-08-06 04:36:26 huajingyun: This probably means the specific ld flag that RUSTFLAGS sets is the cause of the problem: -Wl,-z,pack-relative-relocs 2024-08-06 04:37:09 But we set LDFLAGS to that as well 2024-08-06 04:37:22 So, maybe something in Rust causes this issue 2024-08-06 05:05:07 cely:OK, thank you 2024-08-06 05:05:17 This problem occurred after binutils was upgraded, I am asking my rust colleagues to take a look. 2024-08-06 05:06:18 You're welcome 2024-08-06 05:37:22 efs-utils is actually blocked by the nix crate failing to build on Loongarch, so i could disable it 2024-08-06 05:37:23 However, the next Rust aport to be merged will fail too 2024-08-06 05:43:50 Now i have a clearer picture of what happened 2024-08-06 05:44:24 I actually checked efs-utils when it was merged yesterday, and saw that it wasn't affected by new binutils 2024-08-06 05:45:23 and now it's affected, that's because of dt_relr being enabled on Loongarch in abuild (which is what sets RUSTFLAGS) 2024-08-06 06:07:26 So,binutils was already upgraded to 2.43 before efs-utils was merged, right? 2024-08-06 06:07:40 I just tried to compile rustypaste, and it worked fine with binutils 2.42.,but 2.43 gave the same error as efs-utils 2024-08-06 06:10:02 Did you upgrade abuild? 2024-08-06 06:10:14 to 3.13.0-r4 2024-08-06 06:11:24 I think the chronology was like this: binutils 2.43 merged, then efs-utils, then an abuild upgrade is merged that sets RUSTFLAGS for Loongarch, and finally efs-utils is bumped again to add stunnel as dependency 2024-08-06 06:12:41 Yes, I have upgraded to abuild-3.13.0-r4 2024-08-06 06:12:51 I think all Rust aports will fail on Loongarch now, which is why i'm holding off merging anything 2024-08-06 06:13:22 Did you try building rustypaste with binutils 2.42 and the new abuild 3.13.0-r4? 2024-08-06 06:14:14 Maybe the new Rust flag in question is silently ignored on binutils 2.42 or something 2024-08-06 06:15:59 Yes, rustypaste compiles successfully, I use abuild-3.13.0-r4, gcc-14.2.0-r0 and abuild-3.13.0-r4 2024-08-06 06:16:35 So, probably what you need to focus on is `export RUSTFLAGS="$RUSTFLAGS -Clink-arg=-Wl,-z,pack-relative-relocs"` 2024-08-06 06:16:47 That flag with binutils 2.43 2024-08-06 06:17:31 I have told ncopa about this, but i think the temporarily fix now it to not set RUSTFLAGS for Loongarch in main/abuild 2024-08-06 06:17:36 s/it/is/ 2024-08-06 06:17:56 because even the Rust compiler itself cannot be built on Loongarch with that set 2024-08-06 06:22:39 I'm now trying Rust 1.81.0 beta4, and it still insists on building its own LLD 2024-08-06 06:23:43 I don't really follow Rust PRs on Github closely, but i saw https://blog.rust-lang.org/2024/05/17/enabling-rust-lld-on-linux.html 2024-08-06 06:23:56 However, that's for Rust nightly, no mention of it becoming the default on 1.81.0 2024-08-06 06:25:26 but this is Rust, so we may have to be prepared that the next version could switch from binutils LD to LLD 2024-08-06 06:33:33 huajingyun: maybe we/you can patch musl with your patch on alpine 2024-08-06 06:34:04 and don't wait for new musl release 2024-08-06 06:35:12 (I didn't had time to read my musl folder in my mail server, there are a big heap of unread mails) 2024-08-06 06:38:45 mps:Ok, I'll create a MR later (I originally wanted to wait until musl is merged) 2024-08-06 06:39:36 if you are sure patch is ok, ofc 2024-08-06 06:40:05 cely:I now suspect that binutils may be missing something, I am looking 2024-08-06 06:40:14 could you point me to patch url on musl ML 2024-08-06 06:41:08 mps: https://www.openwall.com/lists/musl/2024/08/02/1 2024-08-06 06:41:21 thanks 2024-08-06 06:42:16 who is lixing? You? 2024-08-06 06:45:28 No, it's my colleague 2024-08-06 06:46:04 s/it/he 2024-08-06 06:50:19 ok, thanks for info 2024-08-06 07:00:51 huajingyun: But weirdly, this seems to affect Rust aports only, so adding that flag to LDFLAGS seems alright 2024-08-06 07:08:00 It seems like that, I noticed it 2024-08-06 07:17:29 Maybe you should open an MR reverting the 4ebab75eb2fa changes for Loongarch 2024-08-06 07:18:00 Otherwise the list of Rust aports that fail will keep blocking the builder 2024-08-06 07:18:20 and hopefully no one pkgrel-bumps the Rust compiler itself in the meantime 2024-08-06 07:21:30 Ok, I might have to do this now. 2024-08-06 07:28:22 I created !70218 2024-08-06 07:40:16 Unfortunately, I'm told that binutils supports these flags, but it's not fully reliable yet. This might be the reason for the rust-related aport reports errors 2024-08-06 07:40:22 I've reported the issue to our binutils team and they'll fix it. 2024-08-06 07:44:25 Ok, that's good, thanks 2024-08-06 07:47:52 cely:Thank you for helping to find this problem in time 2024-08-06 07:48:50 You're welcome 2024-08-06 07:49:09 I'm trying to build rust-analyzer with lld in !70220, it looks like it works 2024-08-06 07:50:45 ncopa:can you help check !70218? Thanks 2024-08-06 07:52:42 cely:You mentioned that future releases of Rust will no longer use binutils ld 2024-08-06 07:52:57 I guess this means lld may have better support for Loongarch 2024-08-06 07:53:18 I think it's something Rust upstream is moving towards, not sure exactly when it will get into a stable release 2024-08-06 07:55:47 Okay, I think that's good 2024-08-06 07:57:03 According to the article i linked to on blog.rust-lang.org, they are already getting people who try Rust-nightly to use LLD, and it seems with 1.81.0, Rust-beta also uses it (at least until the current beta4) 2024-08-06 08:02:23 Alright, will be going AFK now, bye 2024-08-06 08:03:13 Ok,bye 2024-08-06 08:36:19 huajingyun: merged. thanks, and sorry for being overly optimistic :) 2024-08-06 08:51:33 ncopa:Thanks for merge 2024-08-06 08:52:00 And thank you for your trust. I believe that discovering problems will promote loongarch64 to be more perfect. 2024-08-06 14:10:45 !70241 KDE Plasma upgrade incoming, must prepare for mirror 403 issue on the builder 2024-08-06 17:08:56 as we follow gcc 14.2 build issue here !251846 2024-08-06 17:09:12 algitbot: are you sleeping ;-) 2024-08-06 17:09:22 that MR is too big 2024-08-06 17:09:24 community/tuxpaint: fix build with gcc 14.2 2024-08-06 17:09:24 nr 2024-08-06 17:09:39 They are 5 digitsd 2024-08-06 17:09:48 and if it's an issue, you should start with a @ 2024-08-06 17:09:50 # 2024-08-06 17:10:07 oh 2024-08-06 17:10:12 !70247 2024-08-06 17:10:24 copy-paste 2024-08-06 17:10:31 Was it a build id? 2024-08-06 17:10:48 ikke: yes, sorry 2024-08-06 17:10:58 hehe, no worry :) 2024-08-06 17:11:10 it was a pipeline id 2024-08-06 17:11:15 yes 2024-08-06 17:11:15 https://gitlab.alpinelinux.org/alpine/aports/-/pipelines/251846 2024-08-06 17:11:45 and I forgot to bump pkgrel 2024-08-06 17:12:37 had to fight state administration all day :| 2024-08-06 17:14:24 no fun 2024-08-06 17:16:14 no 2024-08-08 01:08:24 !68474 2024-08-08 01:08:48 i create !70293 to remove this aport 2024-08-08 06:16:27 qaqland:Ok, thank you 2024-08-08 07:50:32 The reason for !70302 failed maybe a network problem of loongarch64-builder. 2024-08-08 08:07:18 I think such git fetching is usually worked around by adding the fetched repos into source=, but maybe there are too many of them for this aport 2024-08-08 09:25:42 So, I'd probably prefer to disable it on loongarch64 now, it blocks the builder 2024-08-08 09:25:45 I see it only affects testing/asahi-audio (only aarch64 ) 2024-08-08 09:26:58 cely:Can you help or znley will create a MR 2024-08-08 09:30:27 Disable lsp-plugins? 2024-08-08 09:35:47 Wait a minute, let me see if any URL is blocked by the network. 2024-08-08 09:36:28 I'll be going AFK soon, so let me know when you've finished checking 2024-08-08 09:47:25 Okay, I don't have time to deal with it yet. 2024-08-08 09:55:50 Ok 2024-08-08 09:56:29 One last try then i will disable it 2024-08-08 10:02:32 Disabling 2024-08-08 10:03:01 Done 2024-08-08 10:03:26 Going AFK now, bye 2024-08-08 10:44:29 cely:Thanks 2024-08-08 14:16:06 !70319 2024-08-08 14:27:58 mps: why not look for proper patch? it is difficult to know when those compile flags can be removed 2024-08-08 14:28:34 i have used -fpermissive as documented in gcc 14 porting guide - but only for legacy stuff that will never fix it upstream 2024-08-08 14:28:38 like main/db 2024-08-08 14:33:50 ncopa: too much lines needs to be fixed and not sure would it be accepted upstream 2024-08-08 14:34:45 by using flags which are problem is easier to follow problems, imo 2024-08-08 20:12:23 https://gitlab.alpinelinux.org/a16bitsysop/aports/-/jobs/1471991/raw fails on loongarch, / 2024-08-08 20:12:25 builds/a16bitsysop/aports/community/spdk/src/spdk-24.05/test/common/autotest_common.sh: line 1096: 1232 Illegal instruction (core dumped) "$@" 2024-08-08 20:14:58 anyone available to look at it tomorrow? 2024-08-08 21:19:45 mps: I expect that they already have fixed gdb upstream 2024-08-08 21:32:00 all new loongarch servers are online \o/ 2024-08-08 21:34:41 \o/ 2024-08-08 23:23:33 gdb 15.1 very likely needs !70232 2024-08-09 00:08:04 Took the opportunity to remove the Rust libc patch and enable "rust-analyzer-proc-macro-srv" for Loongarch in !70238 2024-08-09 00:08:15 !70328 * 2024-08-09 00:29:56 It seems with the Gitlab update, URLs in commit messages are no longer automatically turned into links 2024-08-09 00:30:24 At least, URLs to external website, didn't check the !mr and #issue internal links 2024-08-09 00:42:26 mps: This MR (!70232) about musl can fix the gdb error !70319 2024-08-09 00:43:53 That's what i said :) 2024-08-09 00:46:22 cely: Yes,thank you, I just removed the draft 2024-08-09 00:47:49 clandmeter:Thanks a lot! so does this mean that ci and builder have switched to EU now? 2024-08-09 00:47:56 Oh wait, the GDB MR you linked to is different, i was thinking about !70327 2024-08-09 00:49:18 Oh,sorry 2024-08-09 01:27:06 I think i will merge that !70232 so the builder can proceed past main/ 2024-08-09 01:27:10 -that 2024-08-09 01:28:30 lixin has pinged rich, this musl patch should be checked soon https://www.openwall.com/lists/musl/2024/08/02/1 2024-08-09 01:31:36 I think this will also be the first time we are rebuilding musl with the new GCC and binutils 2024-08-09 01:32:32 Ok, will be merging now 2024-08-09 01:35:06 Thanks 2024-08-09 01:38:20 You're welcome 2024-08-09 06:23:24 ikke: let me look at spkd. 2024-08-09 07:32:42 ikke: spdk passed on loongarch64-3A6000. 2024-08-09 07:35:22 What model is the machine reporting the error? 2024-08-09 07:39:05 good morning 2024-08-09 07:39:33 huajingyun: they are online 2024-08-09 07:39:38 Hi,Carlo 2024-08-09 07:39:39 but not prepared 2024-08-09 07:40:17 so need to start infra deployment soon 2024-08-09 07:40:51 clandmeter: Ok, thank you 2024-08-10 20:31:17 we now have 2 servers doing CI 2024-08-10 20:31:31 so i guess we can enable CI per default 2024-08-10 21:03:39 the network is okay now for larger downloads in ci? 2024-08-10 21:12:28 cool that it can be default now 2024-08-11 08:29:41 is the repos still https://dev.alpinelinux.org/~loongarch/edge or have they been moved somewhere else? i am missing packages i would expect to be present 2024-08-11 08:31:03 https://dev.alpinelinux.org/edge is the location the builder is currently uploading to 2024-08-11 08:31:29 what an odd location… 2024-08-11 08:31:31 at least i haven't heard of it being moved from that 2024-08-11 08:33:03 also: is there any known supplier of loongson 3c6000 systems? 2024-08-11 08:33:41 i have 3a6000 machine which i have done a couple of dev streams on now, but would like to find the server variant 2024-08-11 08:37:20 You'll have to wait for Jingyun to answer that tomorrow, i think the servers that have been provided to Alpine are 3c5000 2024-08-11 08:37:57 it’s a fun little architecture 2024-08-11 08:38:32 i’ve been missing some MIPS action since MIPS technologies went bankrupt and pivoted into making risc-v designs 2024-08-11 08:39:53 alright well i will fix my apkrepos then :) 2024-08-11 08:40:18 (also curious to hear about loongarch and NUMA) 2024-08-11 12:07:06 Ariadne: i think think the server version is ready 2024-08-11 12:07:15 dont* 2024-08-11 12:07:30 only the desktop variant 2024-08-11 12:11:24 I'm trying to bootstrap loongarch but im running into a build issue with rust 2024-08-11 12:43:46 https://tpaste.us/ePZb 2024-08-11 16:09:05 I think very likely adding $CBUILDROOT to target.$_target.musl-root will help, but can't be sure without trying bootstrap.sh myself 2024-08-11 16:10:42 Maybe Jingyun can confirm tomorrow, whether $CBUILDROOT was added to that option in ./configure of Rust's APKBUILD (if bootstrap.sh was originally used to get Rust onto Loongarch) 2024-08-11 17:16:40 I’ll check later 2024-08-11 17:16:46 family calls 2024-08-11 20:00:55 cely: you mean like this? https://tpaste.us/wxbO 2024-08-11 20:04:06 Hi! I got an XC-LS6A3M and am interesting in joining the porting effort 🙂. However, before I do anything, I'd like to dump the flash so I have a backup. I found two SPI flash chips with a pin header next and managed to dump both of them. However, one is only 64 KiB, so I doubt that contains the UEFI, the other is 512 KiB but only contains the ethernet NIC. Does anyone know where the UEFI is actually stored? Is there some eMMC somewhere 2024-08-11 20:04:06 that contains it or something? 2024-08-11 20:05:46 this is loongson hw? 2024-08-11 20:07:49 its the asus china one 2024-08-11 20:08:02 which is being sold on aliexpress by a company called "coreboard" 2024-08-11 20:09:07 i have one of those and also the evaluation board which i have been using more recently on twitch to do various development streams on the weekends 2024-08-11 20:12:47 speaking of, last night i tried to get firefox going, but it seems the libc crate vendored in firefox is quite broken on loongarch-musl 2024-08-11 20:13:20 i assume there has to be a working libc crate though because we wouldn't have a working rustc without it 2024-08-11 20:14:14 i am unable to find that sku on google. doesnt yield many results 2024-08-11 20:14:19 nor ali 2024-08-11 20:14:56 https://www.aliexpress.us/item/3256807207300158.html 2024-08-11 20:16:10 weird 2024-08-11 20:16:11 is the one i ordered that isn't the eval board 2024-08-11 20:17:40 heh ali is pretty weird, first it doesnt show any results 2024-08-11 20:17:52 now when i click your name stuff starts to popup 2024-08-11 20:18:06 url* 2024-08-11 20:39:10 the only real notable difference is that the eval board has two boot roms with a jumper to switch between them and the asus china board has an overclocking feature (that you can allegedly patch into the evaluation board UEFI, haven’t tried it myself yet) 2024-08-11 20:40:37 oh and given it’s an asus china production the parent company has no documentation on the SKU, so that’s fun :) 2024-08-11 20:56:36 I wonder if I should just reach out to the ASUS parent company and ask them about it 😛 2024-08-11 20:56:53 while explicitly linking to an article I found where the president of ASUS China presents this board 😛 2024-08-11 23:41:51 yeah it would be nice if i could just buy directly from asus 2024-08-12 00:55:35 clandmeter: Yes, that's the diff i was thinking about 2024-08-12 01:19:01 Ariadne: 3c6000 has not been released yet 2024-08-12 01:19:24 clandmeter: I'll look at the rust bootstrap issue later 2024-08-12 01:22:31 Did you run bootstrap.sh to get Rust onto Loongarch initially? 2024-08-12 01:27:22 I remember you originally had Rust 1.72.1 in dev.a.o/~loongarch/edge-9c13e7 then i came on and mentioned the difficulties in getting new Rust versions (need to go version by version, and some patches that we added to workaround 32-bit ARM issues have to be applied in a very specific way) 2024-08-12 01:28:36 Yes, the original rust is obtained through bootstrap.sh 2024-08-12 01:29:57 I remember that I did not compile it one by one, but cross-built it through bootstrap.sh 2024-08-12 01:31:23 Yeah, i think after 1.72.1, you tried cross compiling 1.76.0 directly, so you wouldn't have to commit the Loongarch patches version by version to aports 2024-08-12 01:31:48 but 1.76.0 was still using llvm17, now we're on llvm18 2024-08-12 01:32:18 What i'm interested in specifically now is, did you have to make any modifications to bootstrap.sh or main/rust/APKBUILD 2024-08-12 01:33:33 Nice, just checked git log for bootstrap.sh, and you made to switch to llvm17 for that 2024-08-12 01:34:10 So, you've probably committed the changes you needed for bootstrap.sh, but what about main/rust/APKBUILD? 2024-08-12 01:36:05 But no, I don't remember changing anything 2024-08-12 01:36:41 Ok 2024-08-12 01:37:20 No worry, I'll take a look 2024-08-12 01:38:58 I tried using crosstool-ng (the git revision with GCC 14.2.0), and i think musl-root will need to be changed 2024-08-12 01:39:38 but there's a second issue, which is i think llvm18 has specific targets enabled based on $CARCH 2024-08-12 01:40:38 https://git.alpinelinux.org/aports/tree/main/llvm18/APKBUILD#n122 2024-08-12 01:42:38 Ok, thanks, I'll keep an eye on it 2024-08-12 01:44:09 I think this interferes with cross compiling Rust, as it seems rustc_driver is built with the targets available in $CBUILD (usually x86_64, which as it isn't conditioned by $CARCH in the APKBUILD, i think all targets are built) 2024-08-12 01:45:23 So, when i tried, it complained about missing references in rustc_driver to targets not enabled on Loongarch 2024-08-12 02:01:07 I'm a bit confused why there is still "-Wl,-z,pack-relative-relocs" in https://tpaste.us/ePZb 2024-08-12 02:14:53 It's in x86_64's /usr/share/abuild/default.conf 2024-08-12 02:15:19 Can you try changing musl root with https://tpaste.us/wxbO ? 2024-08-12 02:17:35 Yeah 2024-08-12 03:03:59 Did it work? 2024-08-12 03:04:01 Using the modification of https://tpaste.us/wxbO, no errors have occurred so far 2024-08-12 03:05:19 Ok 2024-08-12 03:05:43 but it is a bit weird that it did not require that patch when using llvm17 2024-08-12 03:16:19 cely: now it fails 2024-08-12 03:19:41 :( 2024-08-12 03:19:48 Rust is so fragile 2024-08-12 03:20:11 Can you tpaste the error please? 2024-08-12 03:21:56 Same as this error https://tpaste.us/ePZb 2024-08-12 03:24:00 The file /usr/lib/llvm18/lib/libLLVM-18.so is also the same? 2024-08-12 03:24:15 Yes 2024-08-12 03:24:38 Is there a $CBUILDROOT/usr/lib/llvm18/lib/libLLVM-18.so ? 2024-08-12 03:25:07 or maybe you can just tpaste the output of `find $CBUILDROOT/usr` 2024-08-12 03:25:29 So i can see what exactly we are passing to Rust in musl-root 2024-08-12 03:26:30 Maybe not just --set="target.$_target.musl-root, --set="target.$_build.musl-root" may also need to add $CBUILDROOT 2024-08-12 03:27:52 That would make Rust look for x86_64 musl-root under $CBUILDROOT 2024-08-12 03:29:20 $CBUILDROOT/usr/lib/llvm18/lib/libLLVM-18.so exists 2024-08-12 03:29:21 I think maybe we can consider having APKBUILDs that do the cross compiling, as an alternative to bootstrap.sh 2024-08-12 03:29:54 Then if you set target.$_target.musl-root to $CBUILDROOT/usr it should try to link to that libLLVM-18.so 2024-08-12 03:30:05 instead of /usr/lib/lvvm18/lib/libLLVM-18.so from the host architecture 2024-08-12 03:30:09 llvm18* 2024-08-12 03:47:11 Do other arches have the same error? Or is it just loongarch64? 2024-08-12 03:49:15 !70155 mentions that the MR submitter couldn't get Rust or GHC to work 2024-08-12 03:50:02 So, i think that means other archs are affected too 2024-08-12 03:50:14 Probably this is something that happened after the switch to llvm18 2024-08-12 03:50:45 as you could use bootstrap.sh to build Rust 1.76.0 which was still using llvm17 2024-08-12 03:51:04 I have a thought about switching back to llvm17 for the bootstrap, and then rebuild with llvm18 2024-08-12 03:51:15 but i remember a patch that was needed for llvm17 to suppress warnings 2024-08-12 03:51:42 Ok 2024-08-12 03:51:58 According to what you said then, the warnings didn't cause the build to fail 2024-08-12 03:52:34 Yes, I remember 2024-08-12 03:52:42 but this cross compiling of Rust is so fragile, so if there are too many unnecessary warnings, it may be difficult to see what does fail 2024-08-12 03:55:48 Still it is very weird that llvm17 doesn't require changing musl-root, but llvm18 does, and even then it still doesn't solve this issue completely 2024-08-12 04:01:16 I am still working on my crosstool-ng + build llvm manually setup, to see if that will be able to cross compile Rust for Loongarch 2024-08-12 05:39:05 Ok, here's probably something that you can try 2024-08-12 05:41:00 Is $CBUILDROOT/usr/lib/libLLVM.so.18.1 (the file libLLVM-18.so is symlinked to) build for x86_64 or Loongarch? 2024-08-12 05:41:06 or $CBUILDROOT/usr/lib/llvm18/lib/libLLVM.so.18.1 2024-08-12 05:41:13 I wonder if something changed for cross compiling llvm18 2024-08-12 05:54:58 I am now going to do this, first cross-compile llvm18, then rust 2024-08-12 05:55:07 If both /usr/lib/llvm18/lib/libLLVM-18.so and $CBUILDROOT/usr/lib/llvm18/lib/libLLVM-18.so are both built for x86_64, that would explain why they are detected as incompatible 2024-08-12 05:55:13 You didn't cross compile llvm18 first? 2024-08-12 05:56:06 before this, i mean 2024-08-12 05:58:18 If you didn't compile llvm18, and were just using `apk add -X https://dev.alpinelinux.org/edge/main` into target.$_target.musl-root, then it should succeed 2024-08-12 05:58:34 because that's what i'm doing too 2024-08-12 05:59:38 Well, i got some missing references, which i solved by setting target.$_target.llvm-config to the LLVM18 that i compiled 2024-08-12 05:59:49 which does not have so many targets enabled 2024-08-12 06:00:38 Yes, I didn't cross-compile llvm18 when I verified it in the morning, because it would take some time, but I should give it a try now 2024-08-12 06:01:09 Anyway, very weird that an update to llvm18 would necessitate a change in both target.$_target.llvm-config and target.$_target.musl-root 2024-08-12 06:01:35 Well, llvm-config can probably be explained by llvm18 building targets based on $CARCH (which as far as i can see, llvm17 does not do) 2024-08-12 06:02:21 So, the llvm-config of the host and the target now return different supported targets 2024-08-12 06:03:00 or rather, the libLLVM-18.so of the host and target have a difference in the targets they support 2024-08-12 06:04:25 Anyway, when llvm18 is done please tell me if it is compiled for x86_64 or Loongarch 2024-08-12 06:04:56 because when i can't seem to get llvm18 to be cross compiled when i try doing it manually 2024-08-12 06:05:07 Probably i am doing something wrong somewhere 2024-08-12 06:06:36 I am now cross-compiling llvm18,we can wait and see 2024-08-12 06:14:15 Ok 2024-08-12 06:27:15 llvm18 passed, now rust 2024-08-12 06:27:50 Is the llvm18 built for x86_64 or Loongarch? 2024-08-12 06:29:39 Loongarch 2024-08-12 06:29:43 Loongarch llvm18 based on x86_64 cross compilation 2024-08-12 06:30:31 Ok 2024-08-12 06:40:07 Unfortunately, the same error is still reported (Rust APKBUILD added https://tpaste.us/wxbO) 2024-08-12 06:42:35 For the cross compiled LLVM18 2024-08-12 06:42:41 is there a "NATIVE" directory? 2024-08-12 06:43:36 Somewhere in the builddir, for me it's $builddir/llvm/build/NATIVE 2024-08-12 06:43:46 I suspect that we may have to use llvm-config from there 2024-08-12 06:47:30 but it's probably erased after the .apk is created 2024-08-12 06:48:18 Maybe I didn't notice,I checked .apk and there is no NATIVE directory 2024-08-12 06:49:20 Do you still have builddir for Rust? 2024-08-12 06:49:53 If you do, can you tpaste $builddir/config.toml 2024-08-12 06:50:04 I'll compare it with what i have to see where the difference is 2024-08-12 06:50:28 because what i have seems to work, but it isn't based on bootstrap.sh 2024-08-12 06:55:48 Wait, I'll generate a new one for you, I just deleted src 2024-08-12 06:56:23 Actually you don't need to run the build, just ./configure should be enough to generate it 2024-08-12 06:56:44 Yes 2024-08-12 07:03:38 https://dev.alpinelinux.org/~loongarch/hjytmp/config.toml 2024-08-12 07:07:18 Seems to be similar to mine 2024-08-12 07:17:19 So, unfortunately Rust bootstrap is broken 2024-08-12 07:24:51 If we were bootstrapping Rust 1.81.0, i'd say just skip the cross build of Rust, and use a native build, bootstrapped from upstream's host tools (this is how the Rust ecosystem works, you trust upstream's host tools) 2024-08-12 07:24:53 but there are no upstream host tools for 1.80.0/1.80.1 2024-08-12 07:25:22 so, we probably have to go back to llvm17 2024-08-12 07:25:26 Tolerate the warning messages 2024-08-12 07:26:13 disable the -wasm subpackage for the time being (broken due to llvm17 not being default llvm, yes, we had a workaround, you can use that, but who knows what else will break) 2024-08-12 07:26:46 and then rebuild Rust with llvm18 natively 2024-08-12 07:27:50 So, llvm17 stays in bootstrap.sh, main/rust/APKBUILD's _llvmver goes back to 17, and $pkgname-wasm is removed from subpackages= 2024-08-12 07:28:13 That should hopefully make it build 2024-08-12 07:28:48 To avoid having to bump pkgrel on all archs 2024-08-12 07:28:59 maybe we can build Rust 1.80.0 with llvm17 2024-08-12 07:29:19 Then switch to llvm18 with 1.80.1 (what's currently in the repo) 2024-08-12 07:33:38 I have gone back to musl-root = '/usr' 2024-08-12 07:33:40 and it seems to work 2024-08-12 07:33:46 So, that's not the issue 2024-08-12 07:34:00 It is very likely llvm18's llvm-config being broken for cross builds 2024-08-12 07:35:57 probably because of the difference between targets built for $CBUILD (usually x86_64) and $CHOST 2024-08-12 07:37:21 So, the easier way would be to switch back to llvm17 (if that still works, very likely it would), second easiest is to use the vendored llvm18 (will have to stop the build from running out of memory, though) 2024-08-12 07:38:28 with 17 i got an error 2024-08-12 07:38:40 but thats was dependency error 2024-08-12 07:38:42 Yes 2024-08-12 07:38:43 llvm-as 2024-08-12 07:38:47 or something like that 2024-08-12 07:38:48 llvm-ar 2024-08-12 07:38:49 I think 2024-08-12 07:39:06 As i said, you need to remove $pkgname-wasm for llvm17 to work 2024-08-12 07:40:03 I already have the logic in the APKBUILD that disables the wasm targets whenever $pkgname-wasm is not enabled 2024-08-12 07:40:41 So, back to how to fix this 2024-08-12 07:40:56 The harder (but most would probably say the proper) way to fix it would be to fix llvm18 2024-08-12 07:41:04 and with that there is also the easy and hard way 2024-08-12 07:41:16 The easy way would be to just enable all targets again 2024-08-12 07:41:41 but that would probably mean having the llvm18 build time go up 2024-08-12 07:41:50 and not to forget potentially running out of memory 2024-08-12 07:44:06 The harder way would be to "harmonize" the targets, but only during bootstrap (not sure if this will work though, and if it works, it is probably not easy to get right, because that would mean LLVM18 behaves differently during bootstrap) 2024-08-12 07:47:55 If anyone wants to confirm that llvm18 is the problem, then remove -DLLVM_TARGETS_TO_BUILD, and let it build all targets 2024-08-12 07:49:08 but if we only remove that during bootstrap, i am not sure if there will be issues later on, when the bootstrapped Rust is ran against an llvm18 with less targets 2024-08-12 07:51:25 cely: you are sure wasm will break the build? 2024-08-12 07:51:39 im switching back to 17 2024-08-12 07:51:48 When LLVM17 ceased to be default LLVM, -wasm broke 2024-08-12 07:51:58 I added a workaround, which you can get from git history 2024-08-12 07:52:06 but not sure if it's worth it just for bootstrap 2024-08-12 07:52:53 we have llvm in bootstrap purely for rust i guess? 2024-08-12 07:53:09 Very likely 2024-08-12 07:53:14 and the older llvm is for GHC 2024-08-12 07:54:21 ncopa: do you have any comment about this rust boostrapping? 2024-08-12 07:54:25 llvm18 being only for Rust is probably why no other aport in the bootstrap trips over this llvm18 targets issue 2024-08-12 07:58:19 If you really want Rust to be built in the same way as it was when we were using llvm17, then you'll need the Revert frecipe and relax patch from 9c714d89fba032 and explicitly specify llvm17-ar for wasm as 6a7bdeede28 does 2024-08-12 07:59:01 Not sure if the revert patch will apply cleanly, but that was just warnings, and the build doesn't fail 2024-08-12 07:59:40 llvm-ar not being available (renamed to llvm17-ar due to no longer being default llvm), on the other hand, does cause the build to fail 2024-08-12 08:00:59 cely: you are refering to 3cd7f2313dfbc09478c755afd334d70be4e41883 ? 2024-08-12 08:02:01 That was when the llvm17-ar workaround was removed 2024-08-12 08:02:32 Ah yes, and the Revert frecipe and relax patch was removed too 2024-08-12 08:03:15 So yes, reverting that commit should allow Rust to build with llvm17 2024-08-12 08:03:25 unless something else broke in the meantime 2024-08-12 08:04:26 It won't revert cleanly though, because the libc and openssl patches for Loongarch are no longer needed 2024-08-12 08:07:04 Hmm 2024-08-12 08:07:18 im getting a lot of messages 2024-08-12 08:07:21 '+frecipe' is not a recognized feature for this target (ignoring feature) 2024-08-12 08:07:21 '+relax' is not a recognized feature for this target (ignoring feature) 2024-08-12 08:07:30 That's what the Revert frecipe and relax patch is for 2024-08-12 08:07:55 I just thought of something 2024-08-12 08:08:03 ok, is it just a warning or will it break 2024-08-12 08:08:32 When we first encountered it, it was just a warning 2024-08-12 08:08:36 should still be that way 2024-08-12 08:08:40 btw, from that commit, you disabled the wasm option, but did not removed the subpkg? 2024-08-12 08:08:54 I have never disabled wasm 2024-08-12 08:09:11 That would just get complains directed at me :) 2024-08-12 08:10:45 im confused 2024-08-12 08:10:54 removing --set=target.wasm32-wasi.ar=llvm17-ar is a fix? 2024-08-12 08:11:15 the commit msg is not very clear about why its removed 2024-08-12 08:11:16 That was when switching to llvm18 2024-08-12 08:11:45 The default llvm takes llvm-ar, there is no llvm18-ar 2024-08-12 08:11:57 aha 2024-08-12 08:12:03 So, when llvm18 was made default llvm, Rust was still using llvm17 2024-08-12 08:12:09 and we had to explicitly specify llvm17-ar 2024-08-12 08:12:13 or else Rust looks for llvm-ar 2024-08-12 08:12:13 you said you disabled wasm somewhere down the chain right? 2024-08-12 08:12:16 can't find it, and errors out 2024-08-12 08:12:22 No 2024-08-12 08:12:42 I added the logic for wasm to be disabled whenever $pkgname-wasm is removed from subpackages= 2024-08-12 08:13:13 That comes in handy when testing Rust betas, but i have never committed a removal of $pkgname-wasm to aports 2024-08-12 08:14:16 ok with just switching back to 17 and not changing anything else i get the following error 2024-08-12 08:15:43 So, back to the other idea i had 2024-08-12 08:15:43 hmm thats too long to grab from screen 2024-08-12 08:16:06 When cross compiling LLVM18, i think some tools get stashed in a NATIVE/ directory 2024-08-12 08:16:15 error: linking with `loongarch64-alpine-linux-musl-cc` failed: exit status: 1 2024-08-12 08:16:20 Those are compiled for the host 2024-08-12 08:16:37 error: could not compile `llvm-bitcode-linker` (bin "llvm-bitcode-linker") due to 1 previous error 2024-08-12 08:16:37 collect2: fatal error: ld terminated with signal 11 [Segmentation fault] compilation terminated. 2024-08-12 08:17:15 = note: /usr/lib/gcc/loongarch64-alpine-linux-musl/14.2.0/../../../../loongarch64-alpine-linux-musl/bin/ld: BFD (GNU Binutils) 2.43 assertion fail elfnn-loongarch.c:2628 2024-08-12 08:17:41 If we can somehow grab llvm-config from that directory, and use it for target.$_target.llvm-config 2024-08-12 08:17:44 I believe this will fix the build with llvm18 2024-08-12 08:18:07 Do you have abuild 3.13.0-r5? 2024-08-12 08:18:43 but it makes sense that it would use /usr/share/abuild/default.conf from the host 2024-08-12 08:18:55 So, you'll have to unset RUSTFLAGS 2024-08-12 08:19:18 3.13.0-r5 removed RUSTFLAGS for Loongarch 2024-08-12 08:20:14 Sorry, keep confusing host and build, haha 2024-08-12 08:20:36 Previous 2 usage of "host" is actually referring to $CBUILD 2024-08-12 08:21:26 3.13.0-r5 2024-08-12 08:21:30 thats what i have 2024-08-12 08:21:36 Yes, but RUSTFLAGS is set for x86_64 2024-08-12 08:21:44 So, you'll have to unset that 2024-08-12 08:21:53 it causes issues on Loongarch 2024-08-12 08:23:24 and now i wondered why i didn't see that issue, it's because crosstool-ng still uses binutils 2.42 2024-08-12 08:24:13 That issues occurs with binutils 2.43 and -Wl,-z,pack-relative-relocs in RUSTFLAGS 2024-08-12 08:24:34 I think !70229 is a fix for that 2024-08-12 08:29:09 cely: iiuc i need to, switch back to 17, unset RUSTFLAGS in rust pkg, and disable wasm subpkg? 2024-08-12 08:30:26 Yes 2024-08-12 08:31:18 https://tpaste.us/JRo1 2024-08-12 08:31:20 building this now 2024-08-12 08:32:43 Looks good, hopefully there are no other issues 2024-08-12 09:15:17 I just left for a while due to urgent matters 2024-08-12 09:15:23 Switched back to llvm17, any progress? 2024-08-12 09:17:35 failed 2024-08-12 09:17:36 https://tpaste.us/8Mn8 2024-08-12 09:19:29 https://tpaste.us/rjKL 2024-08-12 09:20:35 gcc: error: unrecognized command-line option '-m64' 2024-08-12 09:26:48 "-m64" should be the parameter of x86 (64bit x86), loongarch64 does not have this 2024-08-12 09:29:40 Is abuild installed in $CBUILDROOT? 2024-08-12 09:31:16 but zlib-dev already depends on pkgconfig 2024-08-12 09:31:53 So, that's not it 2024-08-12 09:32:07 It seems to be trying to build zlib 2024-08-12 09:32:30 but has $CTARGET set to x86_64 while using the Loongarch toolchain 2024-08-12 09:33:47 Anyway, this at least means the Rust compiler has built fine 2024-08-12 09:33:57 and it is now choking on Cargo 2024-08-12 09:41:56 https://docs.rs/pkg-config/latest/pkg_config/ 2024-08-12 09:43:24 "This crate will allow pkg-config to be used in cross compilation if PKG_CONFIG_SYSROOT_DIR or PKG_CONFIG is set. You can set PKG_CONFIG_ALLOW_CROSS=1 to bypass the compatibility check" 2024-08-12 09:45:53 We have PKG_CONFIG_ALLOW_CROSS=1 when $_build != $_target 2024-08-12 09:46:07 So, it should allow pkg-config use 2024-08-12 09:46:45 but probably it gets something wrong and can't find zlib in $CBUILDROOT, so it attempts to build it, and gets the compiler flags wrong 2024-08-12 09:57:02 Does bootstrap.sh or abuild set CC to the cross compiler or someything similar? 2024-08-12 09:57:07 -y 2024-08-12 09:57:48 I think it is setting it wrongly, and using the cross compiler when the host compiler is needed 2024-08-12 09:57:54 i only patched bootstrap for the pkgs 2024-08-12 09:58:10 and rust is the patch you say 2024-08-12 09:58:16 saw* 2024-08-12 09:58:56 Ok, it seems i can compile this crate with crosstool-ng 2024-08-12 10:01:02 but CC=gcc when Rust tries to do this 2024-08-12 10:07:15 Oh wait, it seems i only compile this crate for Loongarch 2024-08-12 10:07:21 at least that's where the libz.a is 2024-08-12 10:09:29 So, not sure why it's trying to compile this on x86_64 for you, and with the cross compiler :/ 2024-08-12 10:14:07 i also notice boostrap complains about pax-utils not available for loongarch 2024-08-12 10:14:46 One thing i'm doing differently is, i am setting absolute paths for target.$_target.cc/cxx/ar/linker 2024-08-12 10:15:48 So, the CROSS_COMPILE variable (not using bootstrap.sh, i changed it to another variable) for those settings is not just the triple, but the full path prefix 2024-08-12 10:16:32 but it would be really weird if that affected things in this way 2024-08-12 10:17:20 it may more likely be some environment variable that i have not set 2024-08-12 10:20:13 Logs (the `output` file in those directories) from my build of this crate on x86_64: https://tpaste.us/PE1x (not really a build from what i see), and cross compiled to Loongarch: https://tpaste.us/6MRl 2024-08-12 10:21:35 If anyone has a keener eye for catching the differences in environment variables and so on 2024-08-12 10:23:25 Anyway, that's in my lxc container, so feel free to check it out if you have time and think it could help, but the script and APKBUILD there was put together rather haphazardly (and doesn't use bootstrap.sh) 2024-08-12 10:24:02 I haven't gotten Cargo to build, mostly because i haven't installed OpenSSL into the target's sysroot 2024-08-12 10:24:12 cely: if you want i can copy my repo to your container 2024-08-12 10:24:19 and you can run bootstrap 2024-08-12 10:24:38 it should continue at rust 2024-08-12 10:24:55 That would be interesting, but i'm going AFK, so will only be able to get to that later on 2024-08-12 10:25:16 its ok, i dont think i have time to dive deep into this now 2024-08-12 10:25:38 ill sync it to your packages dir and copy my key to your home 2024-08-12 10:26:10 Alright, go ahead 2024-08-12 10:26:58 is user your local user? 2024-08-12 10:27:01 :) 2024-08-12 10:27:29 Yes, haha 2024-08-12 10:28:00 Going AFK now, bye 2024-08-12 13:02:59 Thanks, ran bootstrap.sh while i was AFK, and now i'm going to see how it did 2024-08-12 13:04:09 Hmm, src/zlib/zutil.c, so it's failing in the same place 2024-08-12 13:17:11 Now i'm trying if a rebuild gets me to the same spot 2024-08-12 13:21:08 I wonder if we should just turn off LTO during bootstrap 2024-08-12 13:24:13 Maybe we can also consider just build rustc and cargo in bootstrap 2024-08-12 13:26:11 That should make the bootstrap go faster 2024-08-12 13:32:28 Added /usr/bin/ to target.$_target.cc/cxx/ar/linker, now trying the build again 2024-08-12 13:36:25 If this also fails, i will probably switch back to llvm18 and see how far the build goes 2024-08-12 13:38:55 but it will be weird if this fails on llvm17 but succeeds on llvm18 2024-08-12 13:39:38 If it's the full path, that is also a bit weird, but config.toml does say to use an absolute path, however that seems to be due to issues building the vendored LLVM 2024-08-12 13:44:14 Before i try llvm18, let me try unsetting CC and CXX (so together with RUSTFLAGS, 3 additional environment variables unset) 2024-08-12 13:45:23 I think CC/CXX is probably the problem, but why did it become a problem now :/ 2024-08-12 13:54:39 That seems to be it 2024-08-12 13:55:04 I don't see the zlib error anymore after unsetting CC and CXX 2024-08-12 17:00:49 For the zlib thing, there is a likelikhood that the last time bootstrap.sh was used on Rust, Rust didn't try to build its own zlib 2024-08-12 17:01:21 which may be why this issue about needing to unset CC/CXX only appeared now 2024-08-13 01:01:28 I still switch to llvm18 to see if can find some clues 2024-08-13 02:15:49 huajingyun: Hi, i am also working on that 2024-08-13 02:46:17 I am in a bit of a dilemma, i don't know if i should check for llvm18 before running the llvm18 bootstrap workaround 2024-08-13 02:59:07 huajingyun: https://gitlab.alpinelinux.org/Celeste/aports/-/commits/improve-rustc-bootstrap-2 seems to fix the llvm18 bootstrap 2024-08-13 02:59:30 If you have time, could you run that too and check if it does for you? 2024-08-13 03:01:01 By the way, were you also working on a solution for llvm18? (I would be interested in seeing an approach that's different from mine.) 2024-08-13 03:11:11 I think it is certain that the problem is not the link search path, but the lack of support for other targets in llvm18 under CBUILDROOT, resulting in missing symbols 2024-08-13 03:11:48 In other words, it is llvm18 that causes 2024-08-13 03:14:04 Yes 2024-08-13 03:14:13 Which is why i am using qemu-user to run llvm-config from $CBUILDROOT 2024-08-13 03:14:30 So Rust is able to get the accurate list of targets from that 2024-08-13 03:15:23 Yeah,i have now seen your" fix the llvm18 bootstrap", it looks good, I am going to give it a try 2024-08-13 03:15:32 Thanks 2024-08-13 03:39:46 I removed these lines for llvm18 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/llvm18/APKBUILD#L121-127 2024-08-13 03:40:15 Now I am cross-compiling llvm18, and then rust 2024-08-13 03:54:11 Will you be able to have a look at $builddir for llvm18? 2024-08-13 03:55:05 With that disabled it is almost certain the Rust bootstrap will work even without my workaround 2024-08-13 03:55:11 I mean, the those lines removed 2024-08-13 03:56:20 If you can look at llvm18's $builddir, maybe you run `find -name NATIVE -type d` in it 2024-08-13 03:56:32 and see if there's a llvm-config under that NATIVE directory 2024-08-13 03:57:34 It should be compiled for x86_64, even though you are cross-compiling llvm18 2024-08-13 03:58:02 I suspect that using that NATIVE/llvm-config as target.$_target.llvm-config will also solve the llvm18 bootstrap issue 2024-08-13 03:58:12 but the consideration is, how do we get that into the .apk 2024-08-13 03:58:27 which is why i went for the solution involving qemu-user 2024-08-13 03:59:01 s/the those/with those/ 2024-08-13 05:55:00 cely:Ok, Rust cross-compilation is passed 2024-08-13 05:57:39 During the llvm18 compilation process, I backed up $builddir, but did not find the NATIVE directory 2024-08-13 06:02:03 Ok 2024-08-13 06:02:13 To be more precise, I removed https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/llvm18/APKBUILD#L122-127, and then cross-built llvm18 2024-08-13 06:02:16 Then I continued to verify https://gitlab.alpinelinux.org/Celeste/aports/-/commits/improve-rustc-bootstrap-2 2024-08-13 06:03:09 Thanks 2024-08-13 06:03:27 You're welcome 2024-08-13 06:08:48 Oh, I forgot to mention that I also removed "-Wl,-z,pack-relative-relocs" in /usr/share/abuild/default.conf for x86_64 2024-08-13 06:08:52 So, maybe we need to "unset $RUSTFLAGS" as well 2024-08-13 06:12:19 That's already done 2024-08-13 06:13:07 In the "unset some env vars while cross compiling" commit 2024-08-13 06:14:15 Ok 2024-08-13 09:34:46 procps-ng tests fail on FAIL: library/tests/test_pids 2024-08-13 09:38:26 i guess related to lxc cap drop? 2024-08-13 09:38:48 huajingyun: did you do something special on your lxc setup? 2024-08-13 09:39:08 :q 2024-08-13 09:39:10 oops 2024-08-13 09:45:45 No special settings 2024-08-13 09:45:47 Did the rebuild fail? 2024-08-13 09:46:13 the tests fail 2024-08-13 09:46:17 one test 2024-08-13 09:47:11 Ok, it failed, I'll take a look 2024-08-13 09:47:24 fails also on your side? 2024-08-13 09:49:10 Yeah,I just rebuilt 2024-08-13 10:11:40 clandmeter: FAIL: check_fatal_proc_unmounted, same error as ppc64le, if you are in a hurry to continue building, you can temporarily !check? 2024-08-13 10:12:06 this or disable that specific check 2024-08-13 10:15:32 It would be better if there was a way to disable that specific check 2024-08-13 10:17:04 patch makefile 2024-08-13 10:17:23 or whatever run tests 2024-08-13 10:18:41 Sorry,i'll be going AFK now 2024-08-13 10:18:45 I'll come back and take a look later. 2024-08-13 10:52:12 i can probably patch it 2024-08-13 10:52:16 if i find time 2024-08-13 11:10:17 it looks like is enough to patch Makefile.am or Makefile.in 2024-08-13 11:10:42 I don't have machine to test this 2024-08-13 11:34:39 I'm back 2024-08-13 11:36:07 Or provide me your patch and I will verify it 2024-08-13 11:36:07 mps:If you have time, you can submit it to CI for verification 2024-08-13 11:39:56 We just built it on 3a6000 and its tests passed 2024-08-13 11:41:11 i guess outside of lxc? 2024-08-13 11:42:20 Docker container (3a6000) 2024-08-13 11:43:04 I think its related to capabilities drop in lxc config 2024-08-13 11:43:18 and im not sure we want to loosen them 2024-08-13 11:44:01 i think we can patch makefile.am and reconf 2024-08-13 11:46:53 huajingyun: I have some free time but it is too hot here for work :-) 2024-08-13 11:48:04 (you will eat your bread in the sweat of your face) 2024-08-13 11:49:10 mps:Ok, thanks:) 2024-08-13 11:54:41 clandmeter:For reference, I just verified that the test also fails in the Docker container (3c5000) 2024-08-13 11:54:55 interesting 2024-08-13 11:57:48 huajingyun: you think its hw related? 2024-08-13 11:57:49 hm, to patch Makefile.am in procps-ng it requires automake-1.16, automake-1.17 doesn't work 2024-08-13 11:57:57 yes 2024-08-13 11:58:00 you need to reconf 2024-08-13 11:58:12 ls 2024-08-13 11:58:26 arg, i need to stop using two screens :) 2024-08-13 11:58:53 you mean 'autogen.sh' 2024-08-13 11:59:38 anyway, I see check is disabled for x86 and ppc64le 2024-08-13 11:59:56 simple thing is to add loongarch to list 2024-08-13 12:00:03 autoreconf -vif i guess 2024-08-13 12:00:11 but thats what autogen does i htink 2024-08-13 12:00:14 ok, lets try 2024-08-13 12:01:12 mps:Just guessing, I'm not sure yet 2024-08-13 12:03:08 my patch work 2024-08-13 12:05:49 oh, just pushed !70457 to CI 2024-08-13 12:06:38 mps 👍 2024-08-13 12:06:42 same as mine :) 2024-08-13 12:06:48 heh 2024-08-13 12:07:18 Thanks!:) 2024-08-13 12:08:32 but it should have better commit msg 2024-08-13 12:11:13 i didnt commt :) 2024-08-13 18:59:58 Oh neat. My XC-LS3A6M apparently came with a debug build of the UEFI. That could come in very handy 🙂 2024-08-14 07:32:43 me and clandmeter has been working on the new build-edge-loongarch64 machine. I will rename the current builder to build-edgetmp-loongarch64 and connect the new one 2024-08-14 07:33:00 the new one will have new apk keys 2024-08-14 07:36:22 we have bootrapped abuild and the aports repo, and once its connected to build.alpinelinux.org we will build the rest of the repositories 2024-08-14 07:37:10 i dont expect too much issues as the repo is in pretty good shape already 2024-08-14 07:37:26 thanks all for the hard work! 2024-08-14 07:37:43 yes. I expect it to go very smooth. all the hard work is done 2024-08-14 07:39:55 the purpose of using new keys is mostly to protect against general distrust. If there are any accusations they will have to accuse us, not longsoon 2024-08-14 07:40:12 or they can read the sources... 2024-08-14 07:41:53 Ok, good to know and totally understand:) 2024-08-14 07:41:57 Thank you very much for your efforts! 2024-08-14 07:42:31 we will rebuild everything from scratch again for the 3.21 release, as we always do 2024-08-14 07:42:56 and thanks to loongarch64, I think the 3.21 will be smoother than normal :) 2024-08-14 07:42:58 thank you! 2024-08-14 07:43:46 Thanks! 2024-08-14 07:44:02 Then it's time for me to close !61715:-D 2024-08-14 07:45:16 So, we are rebuilding everything from scratch now, and will do that again for 3.21? 2024-08-14 07:51:35 cely: correct 2024-08-14 07:51:54 that is the plan 2024-08-14 07:53:48 It ensures that all packages are up to date 2024-08-14 07:55:52 but the side effect is that it will catch all the GCC 14 issues 2024-08-14 07:56:05 So will probably be blocked on main/ and community/ for a while 2024-08-14 07:56:55 right. we will have to fix all those for 3.21 anyway 2024-08-14 07:58:53 and that is also why we keep build-edgetmp-loongarch for a while 2024-08-14 07:59:02 til all packages are rebuilt 2024-08-14 08:00:16 Ok 2024-08-14 08:00:31 Since you're here, if you're not too busy, what do you think of the LLVM18 issue? 2024-08-14 08:00:54 Reducing the targets apparently broke Rust cross-bootstrap 2024-08-14 08:02:22 I have something that seems to work at https://gitlab.alpinelinux.org/Celeste/aports/-/commits/improve-rustc-bootstrap-2 but it involves running the target's llvm-config with qemu-user (so Rust is able to get the correct list of targets enabled) 2024-08-14 08:02:31 but qemu is in community/ while rust is in main/ 2024-08-14 08:02:45 So that may be an issue with my workaround 2024-08-14 08:06:18 Maybe we can consider using a reduced target list (the same one) for all archs, but there will probably be people who start asking for the targets that have been disabled 2024-08-14 08:32:15 maybe we should not reduce the targets 2024-08-14 08:36:12 Yeah, that would be the most straightforward way to fix things 2024-08-14 08:36:21 We didn't do it for previous LLVMs 2024-08-14 08:36:31 which is probably why the bootstrap still works with llvm17 2024-08-14 12:31:29 huajingyun: http://dup.pw/alpine/aports/6d473fb38eff 2024-08-14 13:30:41 when will rebuilding everything start? if it's already started, would probably halt my effort to do a pass through community/, the build server can do it way faster 2024-08-14 13:36:17 unless it's still useful to check backwards from the end for early detection, if the builder is proceeding in alphabetical order 2024-08-14 13:36:56 It should still be useful to check community/, at least until the builder reaches taht 2024-08-14 13:36:58 that* 2024-08-14 13:39:43 okay, will stop at that point 2024-08-14 13:59:40 sorry if most people here have already seen this, just leaving them here in case anyone might have missed them: #16335 #16361 2024-08-14 14:00:56 they were tested on x86_64 but some of them may still apply to loongarch64 2024-08-14 14:07:41 thought might have seen someone from the loongson team fix one of the packages. been updating the lists from time to time, there might still be things that slipped or got missed 2024-08-14 16:10:54 mio: the plan was to get the loongarch64 builder up today, but i bumped into a regression in lua-aports/buildrepo 2024-08-14 16:20:08 okay, thanks for the notice 2024-08-14 16:44:15 new build-edge-loongarch64 is up. the old one is renamed to build-edge-tmp-loongarch64 2024-08-14 16:44:56 new one will upload packages to https://dl-master.alpinelinux.org/alpine/edge/main/ 2024-08-14 16:45:19 which means that the official builder is up! \o/ 2024-08-14 16:50:05 cool \o/ 2024-08-14 17:01:08 hum. it does not upload the build logs properly 2024-08-15 02:30:39 clandmeter:Ok,i see the key, thank you 2024-08-15 04:05:36 It seems source-highlight on build-edge-tmp-loongarch64 still depends on libboost_regex.so.1.82.0, but it seems other archs don't depend on libboost_regex at all 2024-08-15 04:06:05 Maybe we can compare it with build-edge-loongarch64, to see if its source-highlight also dependson libboost_regex 2024-08-15 04:06:12 depends on* 2024-08-15 04:07:06 I'll push a rebuild for now so the tmp builder can be unblocked 2024-08-15 04:07:25 (testing/trace-cmd which has source-highlight in makedepends fails to build due to the dependency issue) 2024-08-15 05:26:22 Ah, build-edge-loongarch64 has built source-highlight 2024-08-15 05:27:40 At least, i think i saw it being built...and now it seems there are only 64 aports left to build in main/ 2024-08-15 05:27:42 :) 2024-08-15 05:27:54 Didn't expect it to be this fast 2024-08-15 07:26:27 would be nice to have build logs... 2024-08-15 07:29:11 morning 2024-08-15 07:29:20 i will have a look at getting the build logs 2024-08-15 07:41:33 Thanks! 2024-08-15 07:48:37 logs are getting uploaded now 2024-08-15 07:50:22 ncopa: how do we know which builders is failing? 2024-08-15 07:50:45 clandmeter: you see it here: https://build.alpinelinux.org/ 2024-08-15 07:50:57 but the link is the same 2024-08-15 07:51:02 at laest up till now 2024-08-15 07:52:27 the old builder's logs should end up here: https://build.alpinelinux.org/buildlogs/build-edge-tmp-loongarch64/ 2024-08-15 07:54:03 ok so the urls in commits channel will change? 2024-08-15 07:57:43 It would be nice if we could see which aports are left to build 2024-08-15 08:05:11 clandmeter: urls in commits channel should be correct? 2024-08-15 08:05:53 i dont see any tmp url? 2024-08-15 08:07:04 i dont see any build failures on tmp url either 2024-08-15 08:07:28 build-edge-tmp-loongarch64 is idle. no errors 2024-08-15 08:08:12 so no build error messages with urls in #alpine-commits either 2024-08-15 08:08:28 edge/main/loongarch64: uploaded 2024-08-15 08:11:19 ok 2024-08-15 09:08:36 im preparing che-dev-1 2024-08-15 09:08:46 it will be the developers box for loongarch 2024-08-15 09:16:55 awesome 2024-08-15 09:20:25 Great!:-D 2024-08-15 14:02:19 perl-gd error seems to be loongarch64 specific https://build.alpinelinux.org/buildlogs/build-edge-loongarch64/main/perl-gd/perl-gd-2.83-r0.log 2024-08-15 19:02:48 t/autodetect.t (Wstat: 4 (Signal: ILL) Tests: 5 Failed: 0) 2024-08-15 19:02:51 alignment? 2024-08-15 19:03:05 could also be fortify 2024-08-15 19:06:10 mozjs115 fails on loongarch64: https://gitlab.alpinelinux.org/chereskata/aports/-/jobs/1483355 2024-08-15 19:06:22 unknown relocation (102) against symbol 2024-08-15 19:07:11 yeah i was running into that in the last dev stream i did where i got wayland up 2024-08-15 19:12:31 https://github.com/llvm/llvm-project/pull/67424 2024-08-15 19:12:48 solution: some flag to make `gas` not emit R_LARCH_ALIGN relocations 2024-08-15 19:15:37 musl also does not support these 2024-08-15 19:15:53 i think we want to disable `-mrelax` on loongarch 2024-08-15 19:17:41 try adding `-Wa,-mno-relax` to CFLAGS 2024-08-16 01:27:11 Ariadne: Since GCC 14 loongarch64 introduces some new relocation types that are not supported in lld17, agree to add `-Wa,-mno-relax` 2024-08-16 01:27:16 Thanks 2024-08-16 01:28:19 Are we still using lld17? 2024-08-16 01:39:00 we could move to lld18 2024-08-16 01:40:31 I am verifying on lld18 2024-08-16 01:42:30 Ah, right, there is lld17 in community/, but main/lld is lld18 2024-08-16 01:43:29 passed on lld (lld18) 2024-08-16 01:46:16 What about perl-gd? 2024-08-16 01:49:21 znley will look at perl-gd later 2024-08-16 01:56:59 Thanks 2024-08-16 02:04:03 perl-gd is an alignment issue most likely 2024-08-16 02:04:18 i recall dealing with that on mips64 2024-08-16 02:04:31 (in libgd itself) 2024-08-16 02:13:17 i need to wrap up some $dayjob work, but i can probably get gd working with a non-maintainer update 2024-08-16 03:27:44 I didn't find a specific reason about perl-gd. 2024-08-16 03:28:17 But build and tested on 3A6000 passed. 2024-08-16 03:29:03 Sorry I know nothing about perl. 2024-08-16 03:30:33 Maybe it has something to do with the newly bootstrapped packages 2024-08-16 03:34:40 Are you using the latest packages? Maybe do `apk upgrade --available` 2024-08-16 03:34:45 because it failed in the CI as well 2024-08-16 03:38:06 Now that i have the build log from other archs to look at, it isn't the "CRC error" that causes the problem 2024-08-16 03:38:12 That appears on all archs 2024-08-16 03:38:44 The issue is "Wstat: 4 (Signal: ILL) Tests: 5 Failed: 0" 2024-08-16 03:51:04 It is the AVIF test that is causing the SIGILL: https://metacpan.org/release/RURBAN/GD-2.83/source/t/autodetect.t#L39 2024-08-16 03:52:31 Specifically: https://metacpan.org/release/RURBAN/GD-2.83/source/t/autodetect.t#L42 2024-08-16 03:53:42 Which i think calls: https://metacpan.org/release/RURBAN/GD-2.83/source/GD.xs#L865 2024-08-16 03:55:29 However, i'm not really a C/XS person, so i think what we need to determine is if this is a libgd issue, or a Perl issue 2024-08-16 03:55:48 If it's Perl and doesn't affect any other aport that uses libgd, then i don't mind just disabling that test 2024-08-16 06:54:12 I also refactored libavif, and it does fail tests 2024-08-16 06:54:14 But libavif and perl-gd both passed the test based on GCC 13 2024-08-16 06:54:45 So maybe we need to solve the libavif test failure problem first, I guess this is due to GCC 14 2024-08-16 06:54:55 Ok, thanks for looking int this issue 2024-08-16 06:54:56 into* 2024-08-16 06:55:13 Yeah, likely the perl-gd issue will clear up once libavif is fixed 2024-08-16 06:55:59 Yes, so now we need to look at libavif 2024-08-16 09:57:26 We found out why libavif failed. linux kernel of loongarch64 does not have vector support enabled. 2024-08-16 09:58:59 perl-gd also passed after we enable vector. 2024-08-16 10:04:02 Fix by !70603 2024-08-16 10:05:08 ncopa: If you have time, please help check this MR 2024-08-16 10:05:17 Thanks! 2024-08-16 10:18:17 interesting 2024-08-16 10:19:17 does all existing loongarch hardware support LSX and LASX? 2024-08-16 10:19:39 or do we only support hardware with vector extensions? 2024-08-16 10:21:50 what happens if we run this kernel on hardware without vector (if such hardware exists?) 2024-08-16 10:22:59 my wild guess kernel will check if extension is supported and use it else will not. to repeat wild guess 2024-08-16 10:52:38 thats how it should work, but the config know says: CONFIG_CPU_HAS_LSX=y 2024-08-16 18:16:10 !253553 2024-08-16 18:16:35 huh !70615 2024-08-16 18:49:37 mps: indentation is borked 2024-08-16 18:49:57 huh 2024-08-16 18:50:09 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/70615/diffs#142eebe2456aaf9cd2906bc48a72a7ef88b2b464_63_63 2024-08-16 18:50:51 fixed 2024-08-16 19:07:12 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/loongarch/Kconfig?h=v6.10.5#n549 2024-08-16 19:07:16 "if unsure, say Y" 2024-08-16 19:07:23 so i think it is fine :) 2024-08-16 19:51:00 +1 2024-08-17 03:19:17 came upon a crate build error that seems to only happen in loongarch64 - !70625 https://gitlab.alpinelinux.org/mio/aports/-/jobs/1486532/viewer#L1402 2024-08-17 03:20:47 could disable the package for loongarch64 for now, posting here in case anyone has any idea for a fix 2024-08-17 03:21:17 Is it linux-sys-raw? 2024-08-17 03:21:48 pyo3-macros-backend v0.21.1 it seems 2024-08-17 03:23:38 It seems to be libc 0.2.153 2024-08-17 03:24:16 Make a patch to Cargo.lock out of `cargo update -p libc --precise 0.2.155` and see if it works 2024-08-17 03:34:51 it worked, thanks ^^ 2024-08-17 03:39:01 You're welcome 2024-08-17 10:36:31 Ariadne: regarding mozjs: 'clang: error: unsupported argument '-mno-relax' to option '-Wa,'' 2024-08-17 10:44:01 I guess it's a direct gcc option, not to the assembler 2024-08-17 11:00:23 clang: warning: argument unused during compilation: '-mno-relax' 2024-08-18 08:11:06 ikke: answer is probably to then move to newer llvm/lld? 2024-08-18 08:11:52 seems it uses lld17 2024-08-18 08:42:54 Ariadne: switching to lld18 fixed it 2024-08-18 08:43:36 ok let’s do that 2024-08-18 08:44:46 !70489 2024-08-18 12:13:25 It seems the vector extensions have been enabled, but the builder won't upgrade to that kernel until all the packages in main/ have built successfully 2024-08-18 12:16:06 (but at least one of the packages, main/perl-gd, won't pass without the kernel with vector extensions enabled) 2024-08-18 12:19:03 sounds like a catch-22 2024-08-18 12:19:45 I guess we have to temporarily disable it 2024-08-18 12:20:12 there are a couple of dependencies as well 2024-08-18 12:20:13 perl-gd? 2024-08-18 12:20:29 yes 2024-08-18 12:20:44 but there may be others that also fail due to the lack of vector extensions 2024-08-18 12:21:06 hmm, they are test failures? 2024-08-18 12:21:13 Is there no way to install that kernel first? 2024-08-18 12:21:24 Yes, perl-gd's is a test failure 2024-08-18 12:21:53 We could copy the apk out of the builder 2024-08-18 12:21:58 Speaking of which, does this mean the builders also restart themselves after the kernel is upgraded? 2024-08-18 12:22:03 no 2024-08-18 12:22:11 Ok 2024-08-18 12:22:44 The host itself is not automatically upgraded, only the builder 2024-08-18 12:23:01 So, it will also require a manual restart after the kernel itself is built 2024-08-18 12:24:03 Someone needs to Install the new kernel and reboot, yes 2024-08-18 12:24:22 I guess we should wait for the kernel to be built first (if it hasn't already) 2024-08-18 12:28:24 Changing the topic a little, do we have some packages that require manual bootstrapping that aren't in bootstrap.sh? 2024-08-18 12:28:46 openjdk? 2024-08-18 12:28:47 I mean, when a new Alpine stable is bootstrapped, i've seen you say you're bootstrapping Go 2024-08-18 12:28:49 Yes 2024-08-18 12:28:55 That's what i was thinking about 2024-08-18 12:29:00 rust as well 2024-08-18 12:29:03 ghc 2024-08-18 12:29:29 Yes, but rust, ghc, and go are in bootstrap.sh 2024-08-18 12:31:18 So..how are we going to bootstrap the four or so OpenJDKs that are enabled on Loongarch? 2024-08-18 12:31:47 I'm not sure, how were they bootstrapped before? 2024-08-18 12:33:40 I think we'll have to ask Jingyun about that, if they have modified bootstrap.sh to be able to cross-compile OpenJDK, or if they used some other method to do the cross-compilation 2024-08-18 12:36:04 I think the only OpenJDK version that was bootstrapped after the (tmp) builder came online was OpenJDK 8 2024-08-18 12:38:53 For that, Jingyun and Znley prepared an .apk and uploaded to dev.a.o/~loongarch/edge, and you gave instructions to install that on the builder through apk -X, so the builder could build it 2024-08-18 12:39:24 uploaded it* 2024-08-19 00:36:30 For the record, the "celeste" currently in #alpine-linux and #alpine-devel is a different person, not me 2024-08-19 00:38:46 Please let me know if you ever notice that person claiming to be me 2024-08-19 00:39:20 I had checked with NickServ when joined OFTC, and that nickname was not available 2024-08-19 00:39:30 when i joined* 2024-08-19 00:39:59 Otherwise i would've registered that 2024-08-19 00:40:37 Now NickServ is telling me that nickname is not registered 2024-08-19 00:44:29 Yes, i've checked my logs, and in November last year, "/msg NickServ INFO celeste" told me that nickname was registered in January 2021 2024-08-19 00:46:26 I've periodically checked for the status of that nickname, and the last time i did so was on 11th June this year, and it was still registered 2024-08-19 00:47:42 I don't think OFTC automatically de-registers nicknames after a period of inactivity, so i'm guessing the person using "celeste" now has gotten OFTC staff to de-register it for them 2024-08-19 00:49:24 Oh well, maybe i should've done that (asked OFTC staff to de-register that nickname) back then, but it's too late for that now 2024-08-19 00:55:23 I have been told that the current "celeste" was using the nickname "triallax" before this 2024-08-19 00:56:00 and NickServ seems to confirm that 2024-08-19 01:29:17 Hi,sorry, missed these messages 2024-08-19 01:29:29 Initially, OpenJDK 8, OpenJDK 17, and OpenJDK 21 were all cross-compiled through bootstrap.sh (add OpenJDK to the PKG list), and before that, we had already locally compiled all the dependencies of OpenJDK and installed them to sysroot, so the cross-building process went smoothly 2024-08-19 01:29:47 So, if we want to get OpenJDK completely from bootstrap.sh, then we also need to cross-build all its dependencies before cross-building openjdk, which will also add more to the PKG list 2024-08-19 01:31:59 Ok, thanks for the information 2024-08-19 01:32:51 I think there is also testing/openjdk22 which is enabled for Loongarch 2024-08-19 01:43:12 cely:Yeah, openjdk22 makedepends openjdk21-jdk and doesn't need its own bootstrap 2024-08-19 01:44:56 Ah okay, thanks 2024-08-19 01:45:39 You're welcome 2024-08-19 01:57:49 ncopa: Thank you for merging !70603, and for loongarch hardware, both the 5000 series and 6000 series support 128 (lsx) vectors and 256 (lasx) vectors 2024-08-19 01:59:20 GCC14 released for the first time supports vector extensions, so we also need to turn on these configurations in the kernel config to enable (such as some vector-related instructions) 2024-08-19 09:21:30 perl-gd keeps blocking, should we consider temporarily disabling the check before upgrade/reboot the kernel? 2024-08-19 09:28:44 i think we can try upgrade/reboot today 2024-08-19 09:30:15 That's the best, thank you:) 2024-08-19 09:38:11 looks like the builders is not coming online 2024-08-19 09:47:11 clandmeter:I guess you don't mean build.alpinelinux.org 2024-08-19 09:47:28 i mean bld2 2024-08-19 09:47:33 ncopa upgraded the kernel 2024-08-19 09:49:48 Ah okay 2024-08-19 10:06:54 probably need to boot the iso and recover 2024-08-19 11:08:50 builder is up again 2024-08-20 01:04:09 clandmeter:Thanks 2024-08-20 10:38:05 huajingyun: I wonder how you guys made the openjdk boostrap possible? looks like some patching is needed. 2024-08-20 11:06:59 clandmeter: hello, openjdk{8,17,21} are completed by me. 2024-08-20 11:09:07 I think I submitted all the patches. If the build tools is complete, it should be able to cross build. 2024-08-20 11:10:40 If there are any cross-build errors, I'll be happy to fix them. 2024-08-20 11:37:05 znley: i tried to cross build 21 by adding it to bootstrap 2024-08-20 11:37:17 but it cannot find the headers of some packags 2024-08-20 11:40:50 Maybe the header files need to be installed in the sysroot. 2024-08-20 11:41:16 did you modify any of the apkbuilds? 2024-08-20 11:41:37 i dont see any cross related code in it 2024-08-20 11:43:16 Yes, no need to modify anything, just adjust to zero variant on loongarch64. 2024-08-20 11:43:42 apk add --keys-dir "/etc/apk/keys/" --no-cache --repositories-file "/home/alpine/repositories" --no-script --root "/home/alpine/sysroot-loongarch64" --initdb --arch "loongarch64" pkgname 2024-08-20 11:43:55 I think znley is installed manually via apk, for reference 2024-08-20 11:44:12 I think currently the aport source code is sufficient to support cross-building. 2024-08-20 11:44:44 huajingyun: Yes, I add makedeps to sysroot manually. 2024-08-20 11:45:07 so we need to do that via the apkbuild 2024-08-20 11:47:00 Does this comply with alpine cross-build strategy? 2024-08-20 12:04:29 By the way, I tried to build openjdk17 with openjdk21, and got the error "configure: (Your Boot JDK version must be one of: 16 17) 2024-08-20 12:04:29 configure: Could not find a valid Boot JDK." 2024-08-20 12:04:34 Or use openjdk17 to build openjdk21, we will get "configure: (Your Boot JDK version must be one of: 20 21)" 2024-08-20 12:04:59 Each openjdk should specify a different range of bootjdk 2024-08-20 12:05:30 This may be a bit like Rust, which needs to be compiled one by one, but for OpenJDK, Alpine currently supports 8, 17 and 21 in community, we may not be able to achieve compatibility 2024-08-20 12:20:35 That's as far as I know it was changed that each jdk now needs the same version to build 2024-08-20 12:22:06 Yes 2024-08-20 15:13:55 bootstrapped openjdk is ok 2024-08-20 15:13:59 except one test failed 2024-08-20 15:59:11 forget about what i said, im tired.. 2024-08-20 16:39:04 It seems openjdk17/21 are bootstrappable purely from packages in main/ 2024-08-20 16:39:41 At least if i can trust my thought process 2024-08-20 16:39:43 lol 2024-08-20 16:40:26 However, openjdk8 depends on gtk+2.0-dev, which is in community/ (there are probably others, but this one jumped out at me) 2024-08-20 16:41:09 Anyone want to try their hand at trimming down openjdk8 makedepends, to see if it can be built from only dependencies in main/ ? 2024-08-20 16:47:48 Additionally, java-cacerts and java-common are in community/ 2024-08-20 17:11:52 Regarding OpenJDK requiring the same version to build, actually, i think that's due to the maintainer of OpenJDK not wanting to support so many versions 2024-08-20 17:12:09 which is why the non-LTS versions were removed 2024-08-20 17:14:22 but i think no one is going to work on the bootstrap path that involves all those intermediate versions, so we'll very likely just be cross-compiling with the same version 2024-08-21 01:23:41 network-extras fails on loongarch64. It seems that ifupdown-ng, which is already installed on the builder, cannot install vlan 2024-08-21 05:25:34 Hmm, it seems the doc() split function of libxcb takes quite a while to complete...the -doc subpackage is 9.4MB 2024-08-21 06:14:28 For anyone interested in openjdk or bootstrap.sh: https://gitlab.alpinelinux.org/Celeste/aports/-/commits/try-openjdk-bootstraps 2024-08-21 06:15:48 With the changes from that branch, i'm able to bootstrap openjdk from x86_64 2024-08-21 06:16:06 though i don't think i'm aiming to have those changes merged 2024-08-21 06:17:15 Good, I'm looking at it,thanks 2024-08-21 09:18:33 Regarding the cross-compilation error of openjdk21, I think it is because the wrong /usr/bin/cc was used during compilation (the correct one should be usr/bin/loongarch64-alpine-linux-musl-cc). We can check the command it executes through fallbackLinker.o.cmdline 2024-08-21 09:19:47 Perhaps it is necessary to modify the configure part in APKBUILD, need to take another look 2024-08-21 10:06:29 clandmeter: I add "--with-boot-jdk=/usr/lib/jvm/java-21-openjdk --with-build-jdk=/usr/lib/jvm/java-21-openjdk" on APKBUILD. 2024-08-21 10:06:57 cross build passed. 2024-08-21 10:07:05 hi 2024-08-21 10:07:07 ok let me try 2024-08-21 10:07:19 see if we can make this apkbuild cross compat 2024-08-21 10:08:10 Yes, I don't know why. Maybe cross-building openjdk21 on riscv also has this problem. 2024-08-21 10:08:33 openjdk17 passed, only openjdk21 needs this modification 2024-08-21 10:12:14 I'm going AFK, hope openjdk builds smoothly 2024-08-21 12:30:37 znley: it worked! 2024-08-21 12:45:41 i have this now: https://tpaste.us/QROz 2024-08-21 12:46:18 i just wonder why the build is looking for zlib and linux-headers outside sysroot 2024-08-21 14:16:54 im building openjdk21 on the builder with my cross pkgs 2024-08-21 14:39:06 but its significantly slower compared to x86_64 2024-08-21 14:47:22 aha 2024-08-21 14:47:29 its not using all the cores 2024-08-21 14:47:36 and it does on my x86 box 2024-08-21 19:31:21 openjdk21 is now available on the edge builder 2024-08-21 23:55:19 That's good news, thanks 2024-08-22 01:00:31 clandmeter:Thanks 2024-08-22 01:02:12 Good news! 2024-08-22 03:26:06 So, nmap and py3-xmlschema have been fixed 2024-08-22 03:27:48 cely:Thanks for merging nmap 2024-08-22 03:29:12 8 more aports left: dev86, rtnppd, ltrace, nfdump, ncftp, ruby-augeas, network-extras, and the last one i can't determine 2024-08-22 03:29:30 You're welcome 2024-08-22 03:30:45 It is probably rtapd, that depends on rtnppd 2024-08-22 03:33:12 network-extras seems to be due to vlan and the already installed ifupdown-ng conflict 2024-08-22 03:33:31 and thanks for the list:-D 2024-08-22 03:36:28 dev86 has !70685, and nfdump has !70691 2024-08-22 03:37:45 Is the patch in !70802 from upstream? 2024-08-22 03:55:37 Ok, so ruby-augeas has also been fixed with an upstream patch, and 3 aports have MRs opened, so that leaves ltrace, ncftp, network-extras, and rtapd (which may pass once rtnppd is fixed) 2024-08-22 04:03:25 Wait a minute 2024-08-22 04:05:58 rtnppd and rtapd upstream may be in this channel :) 2024-08-22 04:09:57 Based on https://sourceforge.net/p/rtnppd/code/commit_browser , i've assigned the rtnppd and rtapd MRs to ncopa (original assignee @ms13sp has no activity on gitlab.a.o) 2024-08-22 04:25:18 ncftp old versions seem to be available at https://www.ncftp.com/public_ftp/ncftp/older_versions/ 2024-08-22 07:54:58 openjdk 17 and 21 are build and available on the edge builder 2024-08-22 08:02:50 The builder is still a few aports away from community/ though 2024-08-22 08:03:39 cely: what is the idea with your work on jdk boostrapping? 2024-08-22 08:03:50 you want to add support for it? 2024-08-22 08:04:01 My idea? :) 2024-08-22 08:04:39 Maybe see if someone else is interested in tidying it up 2024-08-22 08:06:25 There were a few meson aports that i couldn't get to work, so i went back to ./configure instead 2024-08-22 08:06:35 it would be nice if the work we put into it is not lost 2024-08-22 08:10:43 Sure, an alternative would probably be a branch on alpine/aports that gets rebased when it is needed 2024-08-22 08:21:46 what if we just keep the sop like i did now? 2024-08-22 08:22:20 boostrap openjdk later when the packages have already been build on the builder 2024-08-22 08:22:34 so we dont need to crossbuild all of them 2024-08-22 08:22:49 i guess we should move this outside of loongarch discussion 2024-08-22 08:23:01 That would be fine, i think 2024-08-22 08:23:24 Bootstrapping with main/, i mean 2024-08-22 08:23:35 nod 2024-08-22 08:24:02 Though jdk8 needs gtk+2.0, whihch is in community/ 2024-08-22 08:24:09 which* 2024-08-22 08:24:20 do we need all of them? 2024-08-22 08:24:35 these are all lts versions? 2024-08-22 08:24:46 Hehe, good question 2024-08-22 08:25:00 there are not many deps connected to them 2024-08-22 08:25:02 May be time to get rid of one or two 2024-08-22 08:25:34 maybe create an issue and ask the maintainer 2024-08-22 08:25:44 8 has a different maintainer 2024-08-22 08:25:49 They used to be there due to the bootstrap chain 2024-08-22 08:26:04 but since that's disconnected now, less reason to have the older packages I suppose 2024-08-22 08:26:21 The thing about Java is, you build aports with the lowest version, so it will work with the newer ones 2024-08-22 08:26:53 right, but from 8 to 21, thats a lot of building :) 2024-08-22 08:27:04 So, lets say you build with the latest jdk22 in testing/, then the aport will only work on 22 2024-08-22 08:27:06 openjdk8 boostrap does not seem to be very simple to implement through bootstrap.sh, and also requires some manual work 2024-08-22 08:28:06 cely: lets create an issue and discus the best way forward 2024-08-22 08:28:59 I think Timo (@fabled) is focusing on apk-tools now, so maybe if we can't find a maintainer for that, then out it goes 2024-08-22 08:29:10 that = jdk8 2024-08-22 08:30:27 Can some aports with makedepends="openjdk8" upgrade the JDK dependency to a higher version? 2024-08-22 08:30:34 Has anyone tried this? 2024-08-22 08:30:45 Hmm, that would make jdk11 the lowest though, so if that happens, we may have to think about getting it enabled for Loongarch 2024-08-22 08:31:28 It should work, it's just that, as i mentioned above, they won't work with jdk8 anymore 2024-08-22 08:32:47 Ah, and a big one 2024-08-22 08:33:13 No jdk8 means no 32-bit Java ports 2024-08-22 08:33:20 because that's the last ver with 32-bit support 2024-08-22 08:33:57 hmm, that's a strong reason to keep it 2024-08-22 08:34:45 Any one still using 32-bit want to maintain jdk8? ;) 2024-08-22 08:36:03 or maybe we can consider enabling it only for 32-bit 2024-08-22 08:39:12 Haha,this is worth considering:-D 2024-08-22 08:41:15 I have a feeling that some Java aports are getting "miscompiled" for the stable branches anyway 2024-08-22 08:44:27 For example b1b4bfb3f75d4fb, neo4j kept failing when 3.20 was being built, very likely due to there being another jdk-bootstrap being installed that it was preferring over the jdk11 that is a requirement for it 2024-08-22 08:46:57 I think if it did not have such a strict requirement for jdk11, it would then just get built against whatever "preferred" jdk version, with the side effect that it would then not work with any earlier version 2024-08-22 08:48:04 which is probably why so many aports have makedepends="openjdk8" to hopefully force it to be built against that, and so work with every jdk version we have in aports 2024-08-22 08:56:01 Oh, I see 2024-08-22 09:01:47 The reason i sort of pushed for jdk8 in Loongarch is because aports of build tools like apache-ant and maven enforce the use of that, so without jdk8, a lot of Java aports can't be built 2024-08-22 09:02:28 What will those tools do when opnenjdk8 is eol? 2024-08-22 09:02:32 I say "aports", because the tools themself should work with newer versions, but it's the Apkbuild that enforces jdk8, so it can work with latter versions 2024-08-22 09:02:38 ah ok 2024-08-22 09:04:16 We'll need some coordination with the maintainers of those build tools (and the other Java aports), for example, gradle does it differently, preferring jdk8 for 32-bit and jdk21 for all others 2024-08-22 09:06:58 There are MRs that attempt to move apache-ant and maven to other jdk versions (at least for some archs, i think mostly just riscv64): !65004 !63006 2024-08-22 09:09:57 I'll be going AFK, bye 2024-08-22 09:10:34 o/ 2024-08-22 11:26:31 clandmeter:Regarding network-extras, we have to del ifupdown-ng on the new build, to ensure vlan is installed 2024-08-22 12:04:04 Maybe we can do it like that: let Alpine 3.21 be the last version to support Java aports on 32-bit, and after that 32-bit will be JDK-only, so no other Java aport on 32-bit 2024-08-22 13:10:31 huajingyun: what is the prolbem? 2024-08-22 13:27:21 https://build.alpinelinux.org/buildlogs/build-edge-loongarch64/main/network-extras/network-extras-2.0-r0.log 2024-08-22 13:27:44 ok let me build that manually 2024-08-22 13:28:31 ikke: did you add vlan? 2024-08-22 13:28:46 I tried apk add vlan to test it 2024-08-22 13:29:02 :) 2024-08-22 13:29:09 test failed 2024-08-22 13:29:19 or successed with failure 2024-08-22 13:29:24 It was rejected by apk 2024-08-22 13:29:28 succeeded :) 2024-08-22 13:30:08 ok but alpine-base is installed and depends on ifupdown-ng 2024-08-22 13:30:22 why is it in world 2024-08-22 13:32:25 No idea, I did not add that ;-) 2024-08-22 13:33:05 or you cleared you traces like a real hacker 2024-08-22 13:33:37 😶 2024-08-22 13:37:42 --force-broken-world is dangerous :) 2024-08-22 13:40:39 hmm 2024-08-22 13:44:31 so its the ifupdown-ng world entry that is blocking this 2024-08-22 13:44:51 when i remove it from world you can add vlan 2024-08-22 13:44:59 but it will auto remove ifupdown-ng 2024-08-22 13:45:19 and falls back to bb i guess 2024-08-22 13:45:59 ok network extras is build 2024-08-22 13:54:14 I use bb ifuodown everywhere 2024-08-22 13:54:29 ifup* 2024-08-22 21:54:39 only ncftp left for main 2024-08-22 21:54:56 im thinking of disabling it on loongarch as i dont know how to fix it 2024-08-22 21:55:33 its also broken on other arches because of gcc14 2024-08-22 21:56:14 ill add a note if gcc14 support is fixed to enable loongarch again. 2024-08-22 22:03:29 there goes main 2024-08-23 00:27:32 clandmeter: For ncftp, maybe https://gitlab.archlinux.org/archlinux/packaging/packages/ncftp/-/issues/1 will help 2024-08-23 00:28:46 From what i understand, it needs an upgrade to 3.2.7, and -std=gnu89 in CFLAGS 2024-08-23 01:03:18 Great, now builder has switched to community:) 2024-08-23 01:04:56 Hello 2024-08-23 01:06:30 Good morning 2024-08-23 01:15:16 Good morning, i am working on GDC today 2024-08-23 01:15:38 Hopefully i can get it working on Loongarch 2024-08-23 01:24:33 guess can stop running a pass through community/ now, builders can do this fast 2024-08-23 01:26:04 any remaining gcc failed builds not yet reported will reveal themselves 2024-08-23 01:35:06 mio: If you notice failures on #alpine-commits, you can do: 2024-08-23 01:35:08 algitbot: retry master 2024-08-23 01:35:27 So, the builder moves on 2024-08-23 01:36:40 okay, thanks. would it ... loop back after finishing other items in the queue? 2024-08-23 01:39:27 as it occasionally says it fails to build the same packge like it's retrying 2024-08-23 01:39:38 s/packge/package/ 2024-08-23 01:44:24 What do you mean? 2024-08-23 01:44:40 Sure it would eventually return to the same package 2024-08-23 01:44:47 and will continue to do so until it build 2024-08-23 01:46:17 okay, yeah, was confirming that 2024-08-23 01:46:53 i.e. not a cached notification 2024-08-23 03:25:45 cely: Thanks for working on GHC;-) 2024-08-23 03:50:02 No, this is GDC 2024-08-23 03:50:05 Haha 2024-08-23 03:50:24 For D-Lang, not Haskell 2024-08-23 04:10:53 Maybe it is working now, but i had to literally compile a static version of GCC, and use that to bootstrap GDC 2024-08-23 04:13:34 This is to workaround some error at the cross-compile link step of libgdruntime 2024-08-23 04:19:21 gcc-gdc is currently enabled for 3 archs: x86_64, aarch64, and s390x 2024-08-23 04:20:51 In main/gcc/APKBUILD, there are some notes, about 32-bit not working, GDC not being ported to PowerPC, and riscv failing with `static assert "unimplemented"` 2024-08-23 04:21:27 If GDC can be built on Loongarch, i am pondering which other archs to enable 2024-08-23 04:23:12 Perhaps, i will just go the the archs that i managed to get working for GHC (aside from s390x, which doesn't work there) 2024-08-23 04:23:25 s/go the/go with/ 2024-08-23 04:23:48 which means, x86, ppc64le, and hopefully riscv64 2024-08-23 04:25:24 Though i'm not sure i want to dispute the "32-bit not working" part 2024-08-23 04:25:46 as i don't know exactly which part is not working 2024-08-23 04:26:50 So, maybe i should just focus my attention on the three 64-bit archs that are currently not enabled 2024-08-23 04:29:02 also, the Github pull request mentioned for 32-bit is still open, although the Github repo it is under has been archived 2024-08-23 04:29:06 lol 2024-08-23 04:32:19 It is also easier to remember when amending the arch= of D-Lang aports, that 32-bit is not enabled, and should be excluded 2024-08-23 06:04:50 cely:Oh, I misread it, anyway, thank you for doing this 2024-08-23 06:16:41 You're welcome 2024-08-23 06:49:01 huajingyun: Perhaps you could pass this patch: https://tpaste.us/D7qa to your colleagues working on D-Lang 2024-08-23 06:49:07 I made this patch against GCC 14.2.0 source 2024-08-23 06:49:33 but it seems upstream may actually be https://github.com/dlang/dmd/tree/master/druntime/src/core 2024-08-23 06:51:13 Search for "CRuntime_Musl" in those 2 files, that's where i am making those changes 2024-08-23 06:51:49 This is from Loongarch support that was added in musl 1.2.5 2024-08-23 06:53:04 So, after druntime is updated with that, i can build GDC, but the actual cross-compilation process is..... 2024-08-23 06:53:07 messy 2024-08-23 06:53:24 Maybe i'll figure out a way to clean it up as time goes on 2024-08-23 06:53:51 but one step at a time, i think getting musl support for Loongarch into druntime would be a good first step 2024-08-23 06:58:37 Of course, you'll have to double check my changes, i made them based on what i understood of signal.h and fenv.h in the arch/loongarch64/bits directory of musl source code 2024-08-23 06:59:04 cely: OK, got the patch, thanks 2024-08-23 06:59:11 You're welcome 2024-08-23 07:09:01 Alright, going AFK now, bye 2024-08-23 07:18:28 Bye 2024-08-24 01:20:16 The builder has finished 631/5987 packages in community :) 2024-08-24 02:16:56 OCaml 5 being built now 2024-08-24 05:01:24 I may have a tidier APKBUILD for bootstrapping GDC now 2024-08-24 05:43:38 I think a potential issue would be GDC requiring libucontext-dev, which i think causes abuild to additionally trace a dependency on pkgconf, so 2 new dependencies needed to bootstrap GCC 2024-08-24 05:44:02 (that is, if we want to bootstrap GDC as part of GCC) 2024-08-24 07:32:08 https://gitlab.alpinelinux.org/Celeste/aports/-/commits/bootstrap-gcc-gdc-more-archs if anyone is interested 2024-08-24 07:32:28 with the patch i mentioned yesterday, it cross-compiles to Loongarch 2024-08-24 07:33:11 I also tried bootstrap.sh on it for aarch64, and it seems to work; this is just for testing though, as aarch64 already has gcc-gdc 2024-08-24 07:33:43 Finally, ppc64le probably won't work, as it enables druntime only, and not the full libphobos, which seems to be required 2024-08-24 07:35:24 May try 32-bit and riscv64 when i find time later on 2024-08-24 07:35:29 Going AFK now, bye 2024-08-24 07:35:34 o/ 2024-08-24 13:00:48 In addition to the 2 files (signal.d and fenv.d) from my patch yesterday, another file (libunwind.d) has to be patched for community/ldc to build 2024-08-24 13:00:59 but it fails while building tests 2024-08-24 13:01:45 ldc itself seems to work though, i built testing/repology-cli with both gcc-gdc and ldc (on Loongarch), and it builds 2024-08-24 13:02:17 I've pushed the patch for ldc to my "bootstrap-gcc-gdc-more-archs" branch 2024-08-24 16:30:39 Ok, i've updated the branch with a bootstrap.sh that i'm testing now, together with a bootstrap variant of libucontext, as that is required for building gcc-gdc 2024-08-24 16:36:16 I had to remove the pkgconfig files from the bootstrap libucontext, to avoid abuild auto-tracing a dependency on pkgconf (which would mean also having to also bootstrap pkgconf for libucontext to be usable) 2024-08-24 16:36:56 !tracedeps did not help here, as pkgconfig is still added when !tracedeps is in effect 2024-08-24 16:38:27 Anyway, the full libucontext is (re-)built later on after build-base has been bootstrapped 2024-08-24 16:39:51 I think i would be really interested in getting GDC enabled for more archs, for now i'm thinking, Loongarch, and maybe some 32-bit archs too 2024-08-24 16:41:49 ppc64le will likely not work (will take a second look and confirm later), and riscv64 already takes (from memory) 7 hours or so to build GCC, so i'm not sure i want to enable yet another compiler there 2024-08-24 17:37:10 I think the builder has hit one of those Java aports that takes a long time to build on Loongarch: java-postgresql-jdbc 2024-08-24 17:39:06 Hehe, i think it's being built with jdk21, so it will only work on that, and jdk22 from testing 2024-08-24 17:54:38 Yeah, openjdk21 is installed 2024-08-24 17:55:54 (not explicitly on the builder, mind you) 2024-08-25 00:54:00 Yes, openjdk21 is probably installed as a dependency of gradle 2024-08-25 06:28:38 1550 aports from community/ have been built 2024-08-25 08:10:49 2 version are installed 2024-08-25 08:10:56 17 and 21 iirc 2024-08-25 08:14:33 When I checked, only one version was installed 2024-08-25 08:15:17 https://tpaste.us/7MlO 2024-08-25 08:24:15 installed as in added to world? 2024-08-25 08:24:18 or available? 2024-08-25 08:25:18 installed as dependency 2024-08-25 08:25:37 right, it should as its the highest priority iirc 2024-08-25 08:25:56 or maybe the pkg selected it 2024-08-25 08:27:06 gradle explicitly depends on openjdk21 except on arm* 2024-08-25 08:27:15 and x86 2024-08-25 08:28:14 ikke: reminds me, midasi asked what the status our dmvpn is 2024-08-25 08:28:22 of* 2024-08-25 08:28:33 You mean with regards to MTU? 2024-08-25 08:28:37 nod 2024-08-25 08:28:46 I have not noticed any issues anymore personally 2024-08-25 08:29:14 wonder if we should limit the mtu on the tunnel interface? 2024-08-25 08:30:23 and if that makes sense if other spoles do not follow the same 2024-08-25 08:31:32 spokes even :) 2024-08-26 10:21:00 anyone here interested in a list of failed pkgs? 2024-08-26 10:21:09 or is that alraedy obvious? 2024-08-26 19:44:06 clandmeter: probably a lot of overlap with https://gitlab.alpinelinux.org/alpine/aports/-/issues/16335 2024-08-26 19:48:10 i guess those are already fixed? 2024-08-26 19:48:23 and probably dont end up as src dir 2024-08-26 19:49:21 Not all of them 2024-08-26 19:49:47 80 of 151 checklist items completed 2024-08-26 19:49:56 roughly halve 2024-08-26 19:50:35 I tried to fix runit but it will require lot patching so I stopped 2024-08-26 19:50:56 thinking to enable bb runit applets instead 2024-08-26 19:52:41 gst-plugins-good comes down to an incompattibility in ioctl defintion between glibc and musl 2024-08-26 20:03:01 motif can be fixed with 'export CFLAGS="$CFLAGS -Wno-implicit-function-declaration"' 2024-08-26 20:06:02 !70998 2024-08-26 20:14:02 also !70999 2024-08-26 20:16:02 mps: can't you patch it to include stdio.h? 2024-08-26 20:17:01 probably, but I'm tired and don't have much time these days 2024-08-26 20:17:41 just thinking to fix builds and left 'hard work' to maintainers 2024-08-26 20:18:53 usually I don't like to add patches to pkgs for which I'm not maintainer 2024-08-26 20:19:47 I know these CFLAGS additions is not proper fix 2024-08-26 20:20:21 It's very rare someone would object to patches fixing build issues 2024-08-26 20:21:57 imo all these build warnings are bugs but who will have time and patience to fix all them properly 2024-08-26 20:23:03 hopefully the combined effort of us and other distros running into the same issues 2024-08-26 20:23:24 Often it helps to look at upstream if it's already fixed 2024-08-26 20:23:29 upstream should fix these, imo 2024-08-26 20:25:10 yes, ofcourse 2024-08-26 20:25:27 but then we need to wait forever until everything is fixed 2024-08-26 20:25:34 haha 2024-08-26 20:26:11 you are right 2024-08-26 23:35:06 16335 are the gcc 14 ones, there are another ~20 packages found so far of ftbfs unrelated to gcc 14, e.g. failed tests, curl 40x errors on the source tarballs, a handful of rust ones (due to time crate that c e l y informed me how to fix, just fixing those on the side) 2024-08-26 23:37:29 there will be a fair few more not yet listed or may slip through the cracks, since x86_64 has more packages 2024-08-26 23:43:50 that disclaimer aside, so far it doesn't look too bad, main/ looks to be almost done 2024-08-26 23:44:59 if main/ is a representative sample, the gcc issue rate is ~3% 2024-08-26 23:59:30 for now will try to whittle down the 16335 list as it's already sorted 2024-08-27 03:46:18 Perhaps we'll need an automated way of notifying maintainers whenever their aports fail to build 2024-08-27 03:47:27 This would also be a good way of finding out whether maintainers are still active/interested (imo better than looking at whether the aport is at its latest version) 2024-08-27 04:38:36 Doing this automated in a way that makes sense is not trivial 2024-08-27 04:39:17 automated tickets of 'build for package foo on arch y failed' without any details is not that usefull 2024-08-27 04:51:32 also it should only create one issue per package, and not one for each arch that failed 2024-08-27 04:51:56 Ok 2024-08-27 05:40:55 cely: not good idea imo 2024-08-27 05:41:25 I can spam you making your pkgs intentionally to fail on builders 2024-08-27 05:43:37 That would require push access? 2024-08-27 05:44:08 the builder is 3c5000, right? 2024-08-27 05:44:49 a milkv pioneer, so whatever that has 2024-08-27 05:45:35 that's the risc-v 2024-08-27 05:45:39 i meant the loongarch 2024-08-27 05:45:42 but ok, it was just a suggestion, if the suggestion was doable it would probably have been done before, so never mind 2024-08-27 05:46:57 Model Name : Loongson-3C5000 2024-08-27 05:47:03 Ariadne: so yes 2024-08-27 05:47:21 compilation performance seems comparable to octeon 3 2024-08-27 05:47:40 cely: no worries, also I thought earlier about this idea but later concluded opposite 2024-08-27 05:48:14 If someone causes builds to fail on purpose, their commit rights would be revoked rather rapidly 2024-08-27 05:49:01 seems like it would create a headache for infra team, security team, help team, which would all then demand a resolution from the tsc 2024-08-27 05:49:42 ikke: there are smart people around who can make this 'by mistake' ;-) 2024-08-27 05:49:48 in other words, could we not :) 2024-08-27 05:49:54 Anyway, don't want my suggestion to turn into a talk about people causing builds to fail 2024-08-27 05:50:15 if you don't want something to happen don't allow it 2024-08-27 05:50:56 cely: ideas are expressed to be talked about them 2024-08-27 05:51:05 I guess the more fundamental idea i had in mind was, about asking maintainers if they are still interested in fixing issues for aports that they maintain 2024-08-27 05:51:05 ideas* 2024-08-27 05:51:33 If not, maybe they could drop maintainership of the aport in question 2024-08-27 05:51:46 yes, this is what I do 2024-08-27 06:17:08 Will anyone merge the MRs assigned to @itoffshore? For example, 71011 and 70970 2024-08-27 06:28:36 !71011 2024-08-27 06:29:03 hm, do we really need to have lxcfs in repo 2024-08-27 06:29:18 !70970 2024-08-27 06:34:06 mps:Not sure if it's necessary, but the current lxcfs 5.0.4 can't pass the builder 2024-08-27 06:36:44 I didn't upgraded lxcfs for long time because I think it is 'not needed' in repo. don't know if it used by anyone 2024-08-27 06:37:41 but if someone want to merge it I'm not against this 2024-08-27 06:39:09 Both MRs have been merged by Ariadne, thanks 2024-08-27 06:42:22 Ariadne:Thanks 2024-08-27 06:42:25 +1 2024-08-27 07:14:40 libadwaita has some test failures on Loongarch: !67997 "LLVM ERROR: Relocation type not implemented yet!", any idea what's up with that? 2024-08-27 07:17:28 The CI there should still be using packages from dev.a.o, so this is also an issue on the tmp builder 2024-08-27 07:26:16 Regarding libadwaita, riscv64 and loongarch64 have the same error, the reason is similar to community/vtk 2024-08-27 07:26:16 llvm upstream does not seem to allow new architectures to support mcjit, only orcjit.(https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26018) 2024-08-27 07:26:35 I think we need to disable check for loongarch64 and riscv64. 2024-08-27 07:36:36 Ariadne: yes 5000 2024-08-27 07:36:56 oh i wasnt scrolled down 2024-08-27 07:41:22 That will be quite a number of aports that need tests disabled 2024-08-27 07:41:30 Any idea how many? 2024-08-27 07:42:52 I think !68002 is also affected 2024-08-27 07:43:56 So, i think every aport that uses mesa in check() will need that disabled for riscv64 and loongarch64 2024-08-27 08:07:12 cely: Maybe, but I've only seen this test error in vtk before 2024-08-27 08:08:21 vtk, libadwaita, and gtksourceview5 all have mesa-dri-gallium in checkdepends() 2024-08-27 08:08:52 So, maybe that is the criteria 2024-08-27 08:14:38 right 2024-08-27 08:49:27 I successfully built openjdk11 on loongarch64. But it requires '--with-boot-jdk--with-build-jdk' in both the cross-build and local build stages. 2024-08-27 08:51:07 I don't know if it is necessary to submit mr. So I ask for your opinion. 2024-08-27 09:11:34 znley: maybe you can create a MR first 2024-08-27 09:11:54 If added, clandmeter may need to cross-build bootstrap for openjdk11 again 2024-08-27 10:22:41 yes, please create an mr and I will be happy to cross compile it 2024-08-27 11:02:03 create !71027 2024-08-27 12:21:44 Just wondering, did znley use bootstrap.sh to build openjdk11, or was this done by manually installing to sysroot? 2024-08-27 12:22:38 I think it's probably the latter, as that's becoming how we bootstrap OpenJDKs, at least for now 2024-08-27 12:25:53 Yes, I cross build openjdk11 manually. 'CHOST=loongarch64 abuild -r' 2024-08-27 12:27:11 Ok, thanks 2024-08-27 13:02:54 So, i searched through GCC release notes and found the release where GDC bootstrapping changed: https://gcc.gnu.org/gcc-12/changes.html 2024-08-27 13:03:57 "D: Building and bootstrapping GDC, the D compiler, now requires a working GDC (GCC version 9.1 or later) and D runtime library, libphobos, as the D front end is written in D." 2024-08-27 13:49:48 znley: i think we need to update the makedepends for build and host 2024-08-27 13:59:38 cross build is ok 2024-08-27 15:22:34 my first loongson machine booted \o/ 2024-08-27 15:24:20 \o/ 2024-08-27 15:26:00 anyone could tell where is loongarc64 alpine iso image 2024-08-27 15:27:03 mps: https://dev.alpinelinux.org/edge/releases/loongarch64/ 2024-08-27 15:27:28 ah, dev, thanks 2024-08-27 17:34:49 iso image have /etc/apk/repositories set to cdn and not at dev.a.o anyone knows why 2024-08-27 17:38:23 it should be dev.a.o but probably not properly set 2024-08-27 17:38:31 but main is now on cdn 2024-08-27 17:38:36 i guess that should be enough 2024-08-27 17:39:41 well, I need all 2024-08-27 17:50:57 love is all you need 2024-08-27 17:51:42 and some food and wine ofc 2024-08-27 17:52:07 not alpine? 2024-08-27 17:54:48 if you love alpine :) 2024-08-27 17:56:58 didn't know it is an optional dependency 2024-08-27 18:35:43 clandmeter: I'm not new age follower, I don't need love ;-) 2024-08-27 18:37:18 I don't need anything but 'higher power' always put something on me 2024-08-27 21:04:21 ikke: you can edit the 16335 issue list directly, if you wish ^^ 2024-08-27 21:07:05 if you find ftbfs packages. added the ones you mentioned in comments though, thanks 2024-08-27 21:46:05 community/garage seems to be a loongarch-specific FTBFS 2024-08-28 00:35:39 clandmeter: which aport requires update makedepends? 2024-08-28 00:37:24 openjdk11 2024-08-28 00:48:45 Need to separate makedepends_build and makedepends_host, probably like: https://tpaste.us/QROz (clandmeter pasted this a week ago, while working on openjdk21) 2024-08-28 00:57:39 I find code on your repository https://gitlab.alpinelinux.org/Celeste/aports/-/blob/c90d80bae33b3b1ad02281b80f275a29bc63728f/community/openjdk11/APKBUILD 2024-08-28 00:58:06 Is it work well? 2024-08-28 00:59:42 It worked with bootstrap.sh on some other arch (aarch64 or ppc64le, iirc), probably it will work on Loongarch with your changes 2024-08-28 01:00:55 But in general, yes, i think that branch (try-openjdk-bootstraps) should work for bootstrapping openjdk11/17/21 2024-08-28 01:03:19 Ok, let me update my mr. 2024-08-28 01:12:48 Now there has a problem, build openjdk11 on loongarch64 whether cross build or not requires '--with-boot-jdk & --with-build-jdk'. 2024-08-28 01:14:51 Should this be special arguments on loongarch64? 2024-08-28 01:20:11 I think the maintainer of openjdk11 would be better suited to answer that question 2024-08-28 01:20:45 So, maybe you can try asking in your MR 2024-08-28 01:21:42 My view is if the boot/build-jdk's are set to values that are valid for all archs, and doesn't cause the build to fail there, then it doesn't need to be Loongarch-specific 2024-08-28 01:25:30 CI for all architectures passed, so this at least does not affect local compilation for all architectures 2024-08-28 04:38:03 mio: alright, thanks 2024-08-28 07:17:12 will stop edge builder for a shot while 2024-08-28 07:51:21 What's happening? 2024-08-28 07:51:24 OpenJDK bootstrap? 2024-08-28 07:53:03 loooong time didn't used desktop machines, so how much swap space should be big to put machine with 32GB RAM to hibernate aka suspend to disk, anyone have advice for me 2024-08-28 07:54:21 33G? 2024-08-28 07:56:04 doesn't kernel compress RAM when putting it on swap? 2024-08-28 08:01:40 https://docs.kernel.org/admin-guide/pm/sleep-states.html#basic-sysfs-interfaces-for-system-suspend-and-hibernation and description of image_size says swap 'could' be smaller than RAM 2024-08-28 08:02:32 but I have no idea how safe it is, didn't used it more than 15 years 2024-08-28 08:08:26 on my m1pro with 32GB image_size parameter is 13371342848 which is 13MB, approx 2024-08-28 08:08:45 ok, I will experiment to see 2024-08-28 08:39:42 cely: yes but it failed i think 2024-08-28 08:40:08 not sure as i was looking into anotehr crashed thingy (hw) and my desktop suspended.... 2024-08-28 08:40:20 tmux build now 2024-08-28 08:40:48 Ok 2024-08-28 09:37:19 native build is so slow.. 2024-08-28 09:38:36 is it just jdk or are other pkgs also affected? 2024-08-28 09:38:42 i only notice it with jdk 2024-08-28 09:42:33 znley: https://tpaste.us/JR71 2024-08-28 09:42:39 failed to build native 2024-08-28 09:43:20 this is the diff i used https://tpaste.us/8Md8 2024-08-28 09:43:42 ok im turning the builder back on 2024-08-28 09:46:42 I think JDK is the most noticeable 2024-08-28 09:47:34 The timeout should be triggered. 2024-08-28 09:49:21 It is really slow with zero mode. 2024-08-28 09:49:50 Slightly better on 3A6000. 2024-08-28 09:51:01 -rw-r--r-- 1 buildoze buildoze 445.1G Aug 28 09:46 datovka-4.23.8-r0.log 2024-08-28 09:51:05 something went wrong here 2024-08-28 09:52:13 i guess we need to delete that also on distfiles 2024-08-28 09:54:27 build.a.o ? 2024-08-28 09:55:15 I mean we're talking about a build log 2024-08-28 09:55:24 yes its on distfiles 2024-08-28 09:55:31 but could be same as build.a.o 2024-08-28 09:56:00 Hmm, i didn't know that build logs are also on distfiles 2024-08-28 09:58:07 znley: which timeout 2024-08-28 10:00:54 `timeout 3600` in community/openjdk11/APKBUILD 2024-08-28 10:01:27 We changed it to `timeout 5h` for openjdk8 2024-08-28 10:01:36 ah i see it now 2024-08-28 10:01:40 its in the apkbuild 2024-08-28 10:05:51 openjdk11 timeout, https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/openjdk11/APKBUILD#L324 2024-08-28 10:06:08 I have changed it to 2h 2024-08-28 10:08:12 i removed it for now locally 2024-08-28 10:08:20 maybe do a arch switch 2024-08-28 10:09:09 I think it's there just to prevent the aport from blocking the builders, not sure if it's still needed 2024-08-28 10:09:38 openjdk17 also has 5h 2024-08-28 10:09:45 right 2024-08-28 10:10:10 and openjdk21/22 removes the timeout 2024-08-28 10:10:15 would be nicer to have an option, but i think i looked into it, but its hard to timeout a function in shell 2024-08-28 10:12:56 znley: did you run the tests? 2024-08-28 10:15:49 No, I skip tests. 2024-08-28 10:17:32 ok its running again 2024-08-28 10:17:46 remember me to turn it back on 2024-08-28 10:18:51 https://tpaste.us/rjBL 2024-08-28 10:18:58 current list of community failed pkgs 2024-08-28 10:22:41 I'll look into the 2 Perl aports 2024-08-28 10:24:07 If netpbm is failing tests, that is a known issue 2024-08-28 10:24:26 In the past, we've just retried it until it passed 2024-08-28 11:11:09 on iso image dosfstools pkg missing 2024-08-28 11:12:35 but maybe it is not needed locally 2024-08-28 11:38:13 I think there's some misunderstanding in !71027 2024-08-28 11:44:45 Another reason we need some coordination between the various Java maintainers, let's say aports are enabled for openjdk11, but the maintainer of those aports do not want to move to a newer openjdk, and then taking this example, openjdk11 gets enabled on more archs, but the maintainer of openjdk11 rejects that... 2024-08-28 11:45:09 So, that would mean those aports only enabled for openjdk11 will never get on Loongarch 2024-08-28 11:45:47 Well, until openjdk11 gets removed, and there is no choice but to use something newer 2024-08-28 11:45:57 ACTION goes to check how long jdk LTS last 2024-08-28 11:51:51 Don't know where the official information for that is 2024-08-28 11:52:04 but apparently Redhat is going to end support for openjdk11 on October this year 2024-08-28 11:52:52 1h.20m 2024-08-28 11:53:20 build finished 2024-08-28 11:53:25 builder started again 2024-08-28 11:53:27 https://endoflife.date/oracle-jdk shows that extended support will go on until January 2032 2024-08-28 11:53:27 lol 2024-08-28 11:54:22 However fast or slow it builds, it won't matter if the maintainer rejects the MR 2024-08-28 11:54:28 !71027 2024-08-28 11:56:36 why is he talking about rv64? 2024-08-28 11:57:13 If the official sources are saying riscv64 is unsupported, what chance does Loongarch have 2024-08-28 11:57:42 I mean, what are the chances that riscv64 is unsupported "officially", but Loongarch is 2024-08-28 12:08:18 Can't find any mention of Loongarch on https://openjdk.org/jeps/ 2024-08-28 12:09:34 Maybe it hasn't been accepted as an "official" port 2024-08-28 12:24:21 Anyway, if Simon does not want to maintain OpenJDK11 for Loongarch because it isn't officially supported, i'd be willing to maintain it as a separate openjdk11-loongarch aport 2024-08-28 12:47:13 maybe he thinks loongarch == rv64? 2024-08-28 13:07:22 I don't think so, but the situation would be similar, so even if corrected, he would likely just say Loongarch is also not supported 2024-08-28 13:07:36 I mean, he probably mistook the MR for an rv64 one 2024-08-28 13:08:24 and not that he think Loongarch and rv64 are the same 2024-08-28 13:08:42 thinks* 2024-08-28 13:16:41 clandmeter: thanks for the failed pkgs list 2024-08-28 13:41:02 cely: i think we want to prevent an additional pkg, lets try to work out a solution with the maintainer. 2024-08-28 13:41:48 Ok 2024-08-28 14:49:16 uname -a => Linux la.arvanta.net 6.10.6-0-edge #2-Alpine SMP PREEMPT Wed, 28 Aug 2024 14:15:49 +0000 loongarch64 Linux 2024-08-28 14:49:32 first boot with linux-edge 2024-08-28 15:04:33 👊 2024-08-28 16:51:08 is the 16K kernel PAGE_SIZE must for loongarch64 or 4K could be used? 2024-08-29 00:39:29 I think 4K could be used. 2024-08-29 00:57:43 It spent 'real 58m6.071s' to build openjdk11 on 3A6000(loongarch64), skip tests. 2024-08-29 06:16:38 I have got the ball rolling with !71108 and !71109, the aim of that is to get GDC (and later on LDC) enabled on Loongarch 2024-08-29 06:17:04 So, D-Lang aports can also be enabled on Loongarch 2024-08-29 06:18:06 It seems after rebuilding GMP against new GCC, the bootstrap process is working well, at least on x86_64 2024-08-29 06:18:59 Loongarch still needs some patches to the D standard library in order to get GDC enabled for it, an MR for that will come soon 2024-08-29 06:38:00 znley: is it dual socket or the desktop variant? 2024-08-29 06:41:20 3*6000 is the next generation of 3*5000. 2024-08-29 06:42:32 i think the desltop is also 6000 right? 2024-08-29 06:42:32 I think what clandmeter is asking is, which one did you try building openjdk11 on 2024-08-29 06:42:49 which is the latest gen 2024-08-29 06:42:55 and our builders are prev gen 2024-08-29 06:43:11 but the builder is dual socket. 2024-08-29 06:43:23 so my question is, is yours also dual or single socket? 2024-08-29 06:43:36 cely: openjdk maintainer is ok 2024-08-29 06:43:39 Didn't you say you noticed one of the OpenJDKs not using all cores? 2024-08-29 06:43:41 not sure you seen it already 2024-08-29 06:44:09 on Loongarch, that is 2024-08-29 06:44:24 correct, its not using all the cores from simple check 2024-08-29 06:44:34 Yes, i've seen it, but still perplexed why he would oppose riscv64 2024-08-29 06:44:34 but some parts do i believe 2024-08-29 06:48:23 Maybe no one even bothered to get zero mode working for riscv64 on the older JDKs 2024-08-29 06:48:35 Anyway, are you going to add the bootstrap openjdk11 to the tmp builder too? 2024-08-29 06:48:48 Yes, I use 6000 which is desktop. 2024-08-29 06:49:31 cely: not sure, should we? 2024-08-29 06:49:37 This will be relevant to gcc-gdc too, because both openjdk11 and gcc-gdc are not available on the tmp builder 2024-08-29 06:49:52 as in, they are/are going to be newly enabled 2024-08-29 06:50:19 If it isn't added to the tmp builder, wouldn't it be blocked when openjdk11 is enabled? 2024-08-29 06:50:27 we need to think about the tmp builder and what we want to do with it. 2024-08-29 06:51:01 if the main builder is in sync, what are we going to use the tmp builder for? 2024-08-29 06:51:10 Probably that can wait until the official builder has at least uploaded community/ 2024-08-29 06:51:55 Maybe it use single thread at some stage, That's why build openjdk11 on 3A6000 faster than 3A5000, 3A6000 single-core performance is better. 2024-08-29 06:52:06 i can add them later if that is needed 2024-08-29 06:52:29 znley: right, that makes sense 2024-08-29 06:53:38 I think once the official builder has finished all 3 repos, then the tmp builder can just be decommissioned 2024-08-29 06:54:02 btw, current bootstrap.sh does not allow us to modify sysroot apk repositories file? 2024-08-29 06:54:39 Is there such a file? 2024-08-29 06:54:49 I thought everything is controlled with -X? 2024-08-29 06:54:59 there is no repo file correct 2024-08-29 06:55:05 but this is how i used it 2024-08-29 06:55:12 just add the builders repo to it 2024-08-29 06:55:16 Ok 2024-08-29 06:55:28 and it will fetch packages from builder, so its much easier to boostrap 2024-08-29 06:55:29 You mean the local path? 2024-08-29 06:55:39 no i mean a hack :) 2024-08-29 06:55:51 im running httpd on the builder from the pkgs dir 2024-08-29 06:56:03 fetching it over dmvpn 2024-08-29 06:56:21 so all those openjdk deps are fetched instead of build 2024-08-29 06:56:56 but im not sure if its worth modifying bootstrap.sh if you can do this manually 2024-08-29 06:57:09 Ok 2024-08-29 07:03:05 znley: the changes in !71027 will not affect any other arch or native build? 2024-08-29 07:05:02 From the CI result, there is no problem with native build. 2024-08-29 07:05:54 ok, if maintainer agrees lets merge it 2024-08-29 07:06:37 The tmp builder will also attempt to build it though 2024-08-29 07:06:54 btw, not sure its discussed, but will there be attempts to make a non zero variant? 2024-08-29 07:09:45 openjdk does not support other mode on loongarch64. a lot of assembly code is not be allowd to be merged upstream . 2024-08-29 07:16:25 ah ok, attempts were made already? 2024-08-29 07:50:14 Yes, attempt at the begining. 2024-08-29 07:52:34 Is there a repo for that? 2024-08-29 07:54:23 I mean, community/abcl that i maintain took over 7 hours with zero mode, and still didn't complete, so i'm interested in seeing how much faster it would be with a non-zero-mode port 2024-08-29 07:56:40 It depends on openjdk11? abcl 2024-08-29 07:57:01 No, it depends on openjdk8, for now 2024-08-29 07:57:21 For building, that is 2024-08-29 07:58:08 This is the funny thing about Java aports, when building you want the earliest JDK version, so it works with all later versions, but when running you probably want the newest version, haha 2024-08-29 07:58:18 but i'm no expert on Java, so don't quote me on that 2024-08-29 08:03:26 but abcl.org says upstream supports it for jdk8, 11, and 17 2024-08-29 08:03:58 and when i first added it to testing/, i think it got built with jdk22 (being the newest available in testing/) 2024-08-29 08:05:02 So, if you're asking to see if abcl will work with the JDK you all worked on porting, i think most likely it will 2024-08-29 08:05:13 if it is jdk8 and above 2024-08-29 08:06:40 I'll be going AFK, bye 2024-08-29 08:07:01 Try openjdk 21 2024-08-29 08:46:07 so, looks like kernel with 4K PAGE_SIZE doesn't work, at least on 3A6000 2024-08-29 08:56:48 Ok, 3C5000 should be the same.The default PAGE_SIZE is 16K, changing to 4K may cause problems for some software. 2024-08-29 09:07:59 F2FS doesn't work with 16K 2024-08-29 09:08:58 and IME f2fs is very good with flash disks 2024-08-29 09:32:09 ahm, it works with CONFIG_4KB_4LEVEL 2024-08-29 09:32:23 nice 2024-08-29 15:29:02 Hmm, someone is now saying OpenJDK8 isn't the last version with 32-bit support: #16408 2024-08-29 16:25:24 interesting, thought upstream dropped support long ago 2024-08-29 16:26:13 Maybe this is community support 2024-08-29 16:30:42 nods 2024-08-30 01:02:16 What should we do about !71140? (i think @mpolanski isn't really around much lately) 2024-08-30 07:56:15 dev.alpinelinux.org seems to be inaccessible now? 2024-08-30 08:40:01 right 2024-08-30 08:45:44 Ok, not sure what happened 2024-08-30 09:22:00 idk also 2024-08-30 09:49:26 huajingyun: I changed the ip of the host. Let me check 2024-08-30 09:49:46 The ip for dev.a.o retained the same 2024-08-30 09:54:42 Should be reachable again 2024-08-30 13:44:02 2500 aports left to build for community/ 2024-08-30 13:44:24 algitbot: retry master 2024-08-30 15:39:35 community/ratbag appears to be an instance of #16106 ... currently patched to include libgen.h as the use of basename() seems to be limited to error output, but wondering if it would be better to patch out the function call instead 2024-08-30 15:40:28 from the discussion in the community/growlight MR 2024-08-30 15:41:26 That would depend on the maintainer 2024-08-30 15:41:26 error log: http://build.alpinelinux.org/buildlogs/build-edge-loongarch64/community/ratbag/ratbag-0.17-r0.log 2024-08-30 15:41:46 whether they would accept a patch that patches out the function call 2024-08-30 15:42:35 okay, thanks, maybe will wait for maintainer to respond first 2024-08-30 19:20:13 in the case of a glib (not glibc) application, `g_basename` is likely what you want 2024-08-30 19:27:36 Ariadne: thanks, will try that 2024-08-31 21:10:17 There's also a question that's been asked in !67122 2024-08-31 21:10:43 Only tangentially related (because we discussed pkgrel bumps), but more MRs with pkgrel bumps that may not be needed: !67198 !67205 2024-08-31 21:10:43 Maybe if the commit message read "rebuild" it would be reasonable, but in this case it says something else, which imo, does not warrant a pkgrel bump 2024-08-31 21:10:45 and yet more advice to bump pkgrel! !66881 2024-08-31 21:10:47 We really need something written up on when to bump pkgrel 2024-08-31 21:10:47 (by the way, do not follow that advice, bumping pkgrel is not needed to disable loongarch64) 2024-08-31 21:10:49 ACTION goes AFK 2024-08-31 21:12:37 So, my silly bouncer started replaying old messages again :( 2024-08-31 21:12:39 So, nix also needs an upgrade to be compatible with Loongarch? 2024-08-31 21:12:41 Yeah, that's a bit of a problem 2024-08-31 21:12:41 i think that means you must use -p nix@0.23.1 and -p nix@0.24.2 2024-08-31 21:12:45 but probably you'll then run into other errors 2024-08-31 21:12:45 Anyway, thanks for the information 2024-08-31 21:12:51 How's the mqtt-exec/aports-build thing coming along? 2024-08-31 21:12:55 So, J0WI has replied to !67046 2024-08-31 21:12:57 Otherwise, we could be looking at 3 MRs: 1 for adding the new aport, 1 for updating Cargo.lock or go.mod/sum, and 1 for the pkgrel 2024-08-31 21:12:57 I think that's why, for me, at least, i will probably want to check whether new Go/Rust aports are compatible with Loongarch 2024-08-31 21:12:59 Actually, there is no current procedure :) 2024-08-31 21:12:59 bump 2024-08-31 21:13:01 which brought it down to 2 MRs 2024-08-31 21:13:01 and we were actually looking at 3 MRs for some aports, before i suggested that for Rust aports, they could be temporarily disabled, and the Cargo.lock update submitted upstream 2024-08-31 21:13:03 You can always ask for it to be tried out here 2024-08-31 21:13:03 You're welcome