2024-07-01 01:12:51 This is great! build-edge-loongson64 is online, thanks ncopa 2024-07-01 01:13:29 Will you be submitting an MR for libseccomp? 2024-07-01 01:13:33 For libseccomp, I haven't submitted a MR yet because I want to try to wait for 2.6.0 to be released. pcmoore said it might be soon(https://github.com/seccomp/libseccomp/issues/430) 2024-07-01 01:13:38 but there seems to be no progress at the moment 2024-07-01 01:14:48 Is the patch a big one or maybe it affects other archs too (requires rebuilds?) 2024-07-01 01:16:28 I am currently using the 2.5.4 patch, which is about 2k lines long. 2024-07-01 01:18:30 If the patch still works for 2.5.5, you can try uploading it to dev.a.o/~loongarch, and maybe apply it in the APKBUILD for Loongarch conditionally using `case "$CARCH"` 2024-07-01 01:21:57 Ok thanks 2024-07-01 01:22:21 I'll verify and make sure this is working and create a MR as soon as possible 2024-07-01 01:25:02 Ok :) 2024-07-01 01:32:39 znley: Can you help with libseccomp patch verification today? 2024-07-01 01:33:56 There's one more thing I have to do. thanks 2024-07-01 01:35:37 Ok, I will to do it. 2024-07-01 02:08:31 cely: do you know where the packages built by build-edge-loongson64 are uploaded to? 2024-07-01 02:10:28 No, i don't ncopa thought they would go to dev.a.o/~loongarch 2024-07-01 02:10:50 but as libseccomp is blocking main/, as far as i know, nothing has been uploaded until now 2024-07-01 02:13:15 OK, because if it is https://dev.alpinelinux.org/~loongarch/edge/, I am worried that I will overwrite them 2024-07-01 02:13:21 I will occasionally upload the latest locally built packages here 2024-07-01 02:14:40 Yes, maybe you should upload to a different directory now 2024-07-01 02:19:58 It's possible,before creating a new directory, let's ask ncopa to confirm 2024-07-01 02:20:04 thank you 2024-07-01 02:22:07 Ok, that means i will delay merging the libseccomp MR for now, otherwise the upload process will start once main/ is unblocked 2024-07-01 02:22:39 (No MR for that yet though :)) 2024-07-01 02:31:55 I just do something else, but I don't think it will take me too much time. 2024-07-01 02:35:25 No hurry 2024-07-01 07:39:51 Tests have more errors than main branch. 2024-07-01 07:44:31 Yes, i guess that's what ptrc was referring to in #alpine-commits yesterday 2024-07-01 07:46:04 I have contacted the submitter and I believe it will be resolved soon. 2024-07-01 07:46:14 That's good 2024-07-01 08:31:00 Your libseccomp MR probably needs both automake and autoconf 2024-07-01 08:31:31 but if you've tested it and it works on Loongarch, maybe you can apply the patch conditionally for Loongarch with a `case "$CARCH"` 2024-07-01 08:32:27 I mean, it will likely still need autoconf and automake, but i wonder if the patch could break ABI compatibility on other archs 2024-07-01 08:39:34 Alright, i'll be going AFK, so no hurry to get CI green for the libseccomp MR, and we still need confirmation of whether it will upload to dev.a.o/~loongarch/edge 2024-07-01 08:52:50 cely: I am rebuilding the relevant packages based on libseccomp 2.5.5, and when this is completed I will upload them to dev.a.o/~loongarch/edge 2024-07-01 09:05:08 I am checking why the automake was introduced. 2024-07-01 09:11:44 Usually when you change some files, it requires you to rerun automake / autoconf 2024-07-01 09:41:21 I don't know why, but it passed after I upgrade patch. 2024-07-01 09:46:57 Is it necessary to use `case $CARCH` to separate patch for arch*? I am not sure, but it's ok for me if it is necessary. 2024-07-01 09:59:41 The idea is to limit the impact of the patch and not require rebuilds 2024-07-01 09:59:57 Make it easier for maintainers to accept 2024-07-01 11:05:20 ncopa: What's your opinion about !68480. 2024-07-01 12:38:19 Yes, it's probably better to wait for ncopa in this case 2024-07-01 12:39:39 The `case $CARCH` thing i originally heard from @omni, who shared the reasoning behind that idea with me, which is a bit connected with pkgrel not being bumped 2024-07-01 12:41:44 As in, if pkgrel is not bumped, that means for this time, the patch is applied to Loongarch only anyway 2024-07-01 12:44:21 I didn't really agree at that time, and debated with @omni about this, especially if it was to be applied to many aports, but i think in this case maybe it is something that can be considered 2024-07-01 13:57:59 For !68247, if Wenlong thinks the MR is ready then he can take the MR out of Draft (the commit message will also need Draft removed) 2024-07-01 14:33:02 Hehe 2024-07-01 14:35:26 I think we have confirmation that build-edge-loongarch64 uploads to dev.a.o/~loongarch/edge 2024-07-01 14:36:27 You've uploaded libseccomp-2.5.5-r1, and now the builder has moved onto community/ 2024-07-01 14:38:13 Uh oh, i think something is wrong now, /usr/bin/abuild can't find abuild-apk 2024-07-01 14:40:09 I wonder what happened 2024-07-01 14:41:10 But a little bit on the bright side, we now know the number of aports enabled in community: 5888 2024-07-01 14:44:02 how's the ratio relative to other newer/new-ish arches? 2024-07-01 14:45:39 between x86_64 at most packages, and s390x probably fewer packages because different purpose/use cases 2024-07-01 14:49:43 don't know if it's a fair comparison, watching arches like loongarch* and riscv* starting to get more support 2024-07-01 14:50:19 to one day be like a daily driver device ^^" 2024-07-01 14:52:33 I've never noted down the exact number :P 2024-07-01 14:52:54 Give me something in Rust (so it takes a long time :D) to merge and you can see the numbers at build.a.o 2024-07-01 14:54:45 but counting the number of APKBUILDs in community/, it seems to be at 6536 2024-07-01 14:54:59 So, about 650 aports disabled 2024-07-01 14:55:51 cool, sounds like solid proress for a first pass 2024-07-01 14:56:46 (where to find such a package ... the good ones are already taken lol) 2024-07-01 14:57:02 s/proress/progress/ 2024-07-01 15:04:06 Wow, aports-qa-bot has been busy 2024-07-01 15:08:03 the first page is all assignments now after a few original maintainer ones got merged 2024-07-01 15:08:15 also, thanks ^^ 2024-07-01 15:09:43 Ah, yes, for madonctl, you're welcome 2024-07-01 15:15:21 yes ... and, as part of the team of reviewers, taking the time to answer even silly questions and such 2024-07-01 15:15:52 Hehe 2024-07-02 01:10:53 cely: !68247 Draft removed 2024-07-02 01:10:59 I uploaded libseccomp-2.5.5-r1 to dev.a.o/~loongarch/edge last night 2024-07-02 01:11:22 Thank you, i will look into the libc crate MR shortly 2024-07-02 01:12:50 However, we have another problem now. !61715 hasn't been merged, so when you uploaded libseccomp 2.5.5-r1 main/ was unblocked, and build-edge-loongarch64 overwrote main/alpine-keys 2024-07-02 01:13:18 I assume the main/alpine-keys you had in dev.a.o/~loongarch/edge before this had the Loongarch key 2024-07-02 01:13:39 but build-edge-loongarch64 builds from Git master which doesn't 2024-07-02 01:16:50 Yes, the previous main/alpine-keys contained the Loongarch key, maybe ncopa should consider merging this MR in advance 2024-07-02 01:17:41 Maybe you know of some other aport in main/ where the patch for Loongarch has not been merged, but from what i've seen, main/alpine-keys and main/libseccomp are the main ones 2024-07-02 01:18:07 Hopefully, the next time libseccomp is touched, it is the upgrade to 2.6.0 that should have Loongarch compatibility 2024-07-02 01:18:55 I mean, these are the 2 aports that we have to watch out to make sure build-edge-loongarch64 doesn't overwrite 2024-07-02 01:21:27 There are still 3 unmerged MRs in main: main/alpine-keys, main/libseccomp and main/postgresql16 2024-07-02 01:22:34 Maybe you can consider updating main/alpine-keys manually again, as you've already done that with main/libseccomp (both have open MRs so we'll have to see how to deal with that, in case what's merged differs from what you have manually uploaded) 2024-07-02 01:22:55 Ah, so postgresql16 too, make that 3 aports then 2024-07-02 01:22:57 I think 2.6.0 should be fine. The maintainer of libseccomp said that loongarch64 will be supported in 2.6.0. 2024-07-02 01:23:20 Yea, but we can't rule out the possibility that pkgrel is bumped again before 2.6.0 is released :) 2024-07-02 01:24:38 which will cause problems unless !68480 is merged 2024-07-02 01:25:52 Anyway, i think you can go ahead to update main/alpine-keys in dev.a.o/~loongarch/edge manually, and we'll just be on the look out for alpine-keys, libseccomp, and postgresql16 having pkgrel bumped without the Loongarch patches merged first 2024-07-02 01:27:12 Ok, no problem 2024-07-02 01:28:28 This will allow the builder to continue building aports, as now it can't install abuild-apk due to the key not being recognized, so all builds fail 2024-07-02 01:33:08 I am uploading 2024-07-02 01:34:54 Another problem is that I can't upload these software separately because I need to use abuild index to update APKINDEX.tar.gz 2024-07-02 01:36:53 Not really sure i get what you mean, are you saying that `abuild index` also doesn't work now due to main/alpine-keys being overwritten by the builder? 2024-07-02 01:39:08 No, I was overthinking it, it doesn't affect the problem, I uploaded alpine-keys now 2024-07-02 01:40:10 Sorry, I need to leave for a while now, back soon. 2024-07-02 01:41:18 Alright, no worries, i think it should be okay now 2024-07-02 02:38:21 I wonder why the builder is still failing, maybe abuild-sudo needs to be installed manually 2024-07-02 03:08:38 I want to check it out. ncopa should have setup the builder on builder3. 2024-07-02 03:15:13 ncopa: I will go to build-edge-loongarch64 now, or I need to install it manually with abuild-sudo 2024-07-02 03:16:40 Wait, maybe you can try running `apk fix -vi` 2024-07-02 03:16:44 See if it wants to do anything 2024-07-02 03:17:48 Oh, the builder only uses /home/buildozer/packages/main, not dev.alpinelinux.org/~loongarch/edge 2024-07-02 03:23:56 Don't know why ncopa didn't use dev.a.o/~loongarch/edge 2024-07-02 03:34:04 Maybe that is automatically added? 2024-07-02 03:34:46 I mean, at least when the builder tries to install dependencies, probably it's different when you run `apk add` manually 2024-07-02 03:40:59 It doesn't look like it. 2024-07-02 03:41:05 Ok 2024-07-02 03:41:06 This is the current content of the repositories on the builder: 2024-07-02 03:41:06 ~ # cat /etc/apk/repositories 2024-07-02 03:41:06 #https://dev.alpinelinux.org/~loongarch//edge/community 2024-07-02 03:41:06 #https://dev.alpinelinux.org/~loongarch//edge/main 2024-07-02 03:41:06 /home/buildozer/packages/main 2024-07-02 03:43:00 Remove "#" should solve the problem, I think maybe we need to ask ncopa 2024-07-02 03:43:55 Hmm, there's no testing there also 2024-07-02 03:45:55 So i guess the builder upload /home/buildozer/packages/main to dev.a.o/~loongarch/edge/main ? 2024-07-02 03:47:17 it would be best if ncopa could consider merging !61715 2024-07-02 03:47:47 If so, that may be a bit problematic now, as i think /home/buildozer/packages/main should have alpine-keys, which is different from what's in dev.a.o/~loongarch/edge/main (libseccomp wasn't build so it's probably not in /home/buildozer/packages/main) 2024-07-02 03:51:16 Ok, so i think i see the problem now 2024-07-02 03:51:58 When libseccomp 2.5.5-r1, and main/ unblocked, the builder upgraded to alpine-keys that did not have the Loongarch key 2024-07-02 03:52:08 When libseccomp 2.5.5-r1 was uploaded* 2024-07-02 03:52:24 Yes, that's it, so now builder cannot install any packages from /home/buildozer/packages/main because the alpine-keys already installed on builder does not recognize /home/buildozer/packages/main/APKINDEX.tar.gz 2024-07-02 03:55:16 In that case, probably uncommenting dev.a.o/~loongarch/edge will not solve the problem too 2024-07-02 03:55:48 As dev.a.o/~loongarch/edge is signed with the same key as /home/buildozer/packages/main 2024-07-02 03:55:53 or is it a different key? 2024-07-02 03:58:59 I have the latest main/alpine-keys, i downloaded https://dev.alpinelinux.org/~loongarch/edge/main/loongarch64/APKINDEX.tar.gz and ran `apk verify` on it, and it returns "UNTRUSTED" 2024-07-02 04:00:33 So, different key or same key, the packages in dev.a.o/~loongarch/edge will probably also not be installable on the builder, just like those in /home/buildozer/packages/main 2024-07-02 04:10:04 Hmm, ok, i think i got some details wrong there 2024-07-02 04:10:58 The Loongarch APKINDEX.tar.gz should still return "UNTRUSTED" if i am running `apk verify` on it with x86_64 2024-07-02 04:11:09 even once the MR is merged, i mean 2024-07-02 04:11:21 Anyway, i guess this means /etc/apk/keys on the builder is now empty? 2024-07-02 04:36:08 For !68528, "la.patch" seems to not be included, and is it really necessary to add a patch and !check for Loongarch if it's going to be disabled anyway 2024-07-02 05:26:47 Anyway, sorry if in my attempt to help, i may have complicated the situation a bit 2024-07-02 05:28:13 cely: /etc/apk/keys is indeed empty 2024-07-02 05:36:41 Yes, that's because !61715 has not been merged 2024-07-02 05:38:28 I think huajingyun mentioned that besides the alpine-keys MR, there is also !65623 and !68480 2024-07-02 05:39:36 These 3 aports are in dev.a.o/~loongarch/edge, but if they are touched again without those MRs getting in first, then they will fail on Loongarch 2024-07-02 05:40:18 Well, if libseccomp is upgraded to 2.6.0 (whenever this is released) then that MR can be disregarded 2024-07-02 05:40:49 and i guess we are already experiencing the effects of alpine-keys being rebuilt without the changes from that MR 2024-07-02 06:16:29 I got back 2024-07-02 06:19:59 Welcome back 2024-07-02 06:21:09 you are right, /etc/apk/keys is indeed empty 2024-07-02 06:21:31 we can temporarily copy /home/buildozer/.abuild/xxx.rsa.pub to /etc/apk/keys to solve this 2024-07-02 06:21:41 but it is better to see what ncopa thinks, maybe he is willing to merge !61715 2024-07-02 06:24:26 !68528 updated, thanks for your reminder cely 2024-07-02 08:04:14 ncopa: Is it time to merge !61715 ? builder is blocked. 2024-07-03 01:43:34 The builder is still blocked. I am not sure if it is appropriate for me to fix it without ncopa's consent. 2024-07-03 01:43:41 Maybe ncopa has his considerations, but ncopa did not respond yesterday. 2024-07-03 01:44:26 Yeah..i guess he was busy, most likely due to that OpenSSH issue 2024-07-03 01:49:18 Is it the issue mentioned in #alpine-devel? 2024-07-03 01:51:03 Yes, the upgrade which i think may cause people to lose SSH access 2024-07-03 02:01:07 yes, 2024-07-03 02:02:35 I see that alpine-keys now fails to build, so i think that means it was removed (from /home/buildozer/packages/main), maybe that was part of a solution 2024-07-03 02:03:54 Let me go and have a look 2024-07-03 02:06:39 No, it still exists. /home/buildozer/packages/main/loongarch64/alpine-keys-2.5-r0.apk 2024-07-03 02:08:11 Ok, what fails to build is version 2.4-r1 2024-07-03 02:08:34 You can see it on https://build.alpinelinux.org/ now 2024-07-03 02:09:37 Actually, that's the version currently in Git master 2024-07-03 02:13:09 Yeah. 2024-07-03 02:13:17 I see. It seems that ncopa should have synchronized https://dev.alpinelinux.org/~loongarch/edge/main/ to /home/buildozer/packages/main in advance. 2024-07-03 02:13:44 Include community and testing 2024-07-03 02:14:17 https://dev.alpinelinux.org/~loongarch/edge/main/loongarch64/alpine-keys-2.5-r0.apk 2024-07-03 02:18:03 alpine-keys installed in the builder is 2.4-r1 2024-07-03 02:19:20 Yes, i think that's the one with an empty /etc/apk/keys 2024-07-03 02:21:47 yes, alpine-keys should be manually upgraded to 2.5-r0 2024-07-03 02:23:43 So, /home/buildozer/packages now contains community and testing (from dev.alpinelinux.org/~loongarch/edge) too? 2024-07-03 02:25:13 Yes,community,main and testing 2024-07-03 02:26:05 Ok 2024-07-03 02:32:03 If alpine-keys-2.5-r0 is not merged in advance, the existing 2.5-r0 will be deleted after builderepo is built. 2024-07-03 02:34:39 Probably that is something you need to discuss with ncopa, i'm not sure if he was aware that you've uploaded 2.5-r0 to dev.a.o/~loongarch/edge 2024-07-03 02:37:02 Yeah.I will use my afternoon to discuss with him. He should not be online yet. 2024-07-03 02:38:04 By the way, can you help me look at this? !68548 error:No module named 'imp', but CI still passed, I am a little confused 2024-07-03 02:40:23 It should be 'importlib' now, with Python 3.12 2024-07-03 02:40:52 There are a few patches in aports for that, with a quick grep, i find one in community/gpodder-adaptive 2024-07-03 02:45:00 Hmm, py3-oscrypto's check() looks a bit weird, probably it is that `|| sh -l` part that causes CI to still pass even though check() errors out 2024-07-03 02:46:25 You can try patching it with https://github.com/wbond/oscrypto/commit/3865f5d528 2024-07-03 02:47:19 Yes, just confused why every architecture passed in CI, but failed with this error when compiled locally 2024-07-03 02:47:59 Probably it is that `|| sh -l` part that behaves differently locally vs in CI 2024-07-03 02:48:45 it's possible 2024-07-03 02:48:48 thank you,I will fix it 2024-07-03 02:49:04 You're welcome 2024-07-03 02:50:09 When you've fixed it, feel free to ping the maintainer @nmeum, or i can assign it to him 2024-07-03 02:50:42 Ok,thanks 2024-07-03 02:50:45 It doesn't get auto-assigned, probably due to the "+alpine" part in the email address in the Maintainer field 2024-07-03 02:51:37 Ok 2024-07-03 04:42:19 cely: there is logic to check the email without the +tag as well 2024-07-03 04:44:32 Ok 2024-07-03 06:36:36 hi! 2024-07-03 06:36:48 sorry, was busy with the openssh business yesterday 2024-07-03 06:37:25 Hello 2024-07-03 06:41:52 so i messed something up, but not sure what 2024-07-03 06:42:17 maybe I shouldnt have uploaded to dev.a.o/~loongarch/ ? 2024-07-03 06:43:30 I think the main issue is that Jingyun is still uploading .apk's manually to dev.a.o/~loongarch/edge 2024-07-03 06:44:24 There's now an alpine-keys-2.5-r0 at dev.a.o/~loongarch/edge, built out of that unmerged MR 2024-07-03 06:45:04 Well, libseccomp-2.5.5-r1 also, even though the MR is still open 2024-07-03 06:46:22 oh.. 2024-07-03 06:46:50 ok i'll try fix the upload location 2024-07-03 06:47:18 and what went wrong is /etc/apk/keys is now empty, as libseccomp was originally blocking main/, but after it was manually uploaded to dev.a.o, main/ unblocked, and the builder overwrote alpine-keys, and installed that 2024-07-03 06:47:50 re keys, I talked with the other devs and I thiknk the current plan is to create a new apk key once the new builders are in place 2024-07-03 06:48:09 which is why I have been delaying the apk-keys MR a bit 2024-07-03 06:48:10 The alpine-keys that was originally installed on build-edge-loongarch64 had the Loongarch key 2024-07-03 06:48:30 but the current has not i suppose 2024-07-03 06:48:39 Yes, which is why /etc/apk/keys is empty 2024-07-03 06:48:52 so two problems 2024-07-03 06:48:54 and apparently, the builder uninstalled abuild-sudo 2024-07-03 06:49:31 probably as an after effect of /etc/apk/keys being empty 2024-07-03 06:49:46 1) upload location is conflicting with huajingyun 2024-07-03 06:49:57 2) apk-keys gets empty 2024-07-03 06:50:53 If you use a new upload location, won't that mean the builder starts from scratch (probably unless you copy over main/ community/ testing/ from dev.a.o/~loongarch/edge)? 2024-07-03 06:51:16 it means it starts from scratch unless I manually copy the apks, yes 2024-07-03 06:51:22 i thikn i will copy them 2024-07-03 06:51:45 but it might be that we build everything from scratch once the new builder is in place. not sure 2024-07-03 06:51:54 for 3.21 we will build from scratch anyway 2024-07-03 06:52:07 A new upload location does not mean it will rebuild everything 2024-07-03 06:52:15 Maybe we should back up a little, and see if it's possible that Jingyun stop manually uploading things to the upload location used by the builder 2024-07-03 06:52:39 but that means the builder will get blocked due to the MRs that are not merged 2024-07-03 06:52:43 libseccomp is an example 2024-07-03 06:53:16 (that's partially due to libseccomp upstream seemingly "delaying" the next release) 2024-07-03 06:53:33 i think its better that jingyun has a space for uploading whatever, and that the builder uploads somewhere else. we dont need rebuild from scratch for that 2024-07-03 06:54:11 not sure if we want upload to dl-master (and cdn) just yet 2024-07-03 06:56:27 I think the builder will very likely get stuck at community/ 2024-07-03 06:57:11 Jinyun mentioned that besides main/alpine-keys, there's also main/postgresql16 tests (!65623) that could potentially block the builder at main/ 2024-07-03 06:57:21 Sorry, main/libseccomp, not alpine-keys 2024-07-03 06:57:59 If those 2 aports get rev-bumpped without their Loongarch MRs merged first, that is 2024-07-03 07:01:24 So, maybe we can have the builder concentrate on main/ and community/ for now, and see if it's possible to stop fixing issues there by manually uploading .apks 2024-07-03 07:06:31 I think very likely most of the patches needed for community/ already have MRs for them, as it seems most of the Loongarch MRs lately have been for testing/ (lots of aports that haven't been rebuilt in a while there) 2024-07-03 07:27:32 upload location is conflicting, I think it might be better for builder and I to have a different upload location 2024-07-03 07:27:34 and we won't rebuild everything too 2024-07-03 07:27:46 apk-keys gets empty, we can copy /home/buildozer/.abuild/alpine-devel@lists.alpinelinux.org-638db73e.rsa.pub to /etc/apk/keys/ to temporarily solve the current dilemma 2024-07-03 07:27:58 But of course, this is only temporary, only alpine-keys MR merge can avoid similar problems in the future, otherwise we need to manually copy this file every time when there is a problem, otherwise the apks in dev.a.o/~loongarch/edge will not be available 2024-07-03 07:32:06 If consider creating a new apk key, then you can also consider having two keys on loongarch64 at the same time? 2024-07-03 07:32:38 other arches also have 1 or more 2024-07-03 07:44:48 cely: About 20 left in the community, and our team is also fixing them 2024-07-03 07:47:59 Ok, 20 isn't that much 2024-07-03 07:56:41 Yeah.. 2024-07-03 09:09:02 I am moving the build-edge-loongarch64 directory. I have made hardlinks to ~/loongarch so we don't need rebuild everything from scratch 2024-07-03 09:09:09 or copy every thing from scratch 2024-07-03 09:09:53 you find it here for now: https://dev.alpinelinux.org/edge/ 2024-07-03 09:23:10 That's great, thank you ncopa 2024-07-03 09:26:29 ncopa: What about the alpine-keys MR, what will you do with it? 2024-07-03 09:26:38 would you still consider merging it? 2024-07-03 09:28:17 im still thinking of it. the challenge is that once it is added, it may be difficult to delete it 2024-07-03 09:34:51 Ok,waiting for your decision 2024-07-03 09:34:58 There are two unmerged MRs in main, main/libseccomp and main/postgresql16 2024-07-03 09:45:40 I'll be going AFK soon, but i just had a funny idea, maybe alpine-keys could be disabled for Loongarch, and another main/alpine-keys-loongarch package (only enabled on Loongarch) created that provides "alpine-keys" 2024-07-03 09:46:23 So, if it ever needs to be deleted, it can be deleted at the individual/separate package level 2024-07-03 09:46:45 hi 2024-07-03 09:46:51 o/ 2024-07-03 09:47:06 why channel doesn't have topic 2024-07-03 09:47:28 No one bothered to set one 2024-07-03 09:55:14 For !68609, i'm not sure if patching Waf is a good way to go about fixing it 2024-07-03 09:55:33 After all, you can see the line "WARNING! Do not edit!" in the patch file 2024-07-03 09:57:54 I have worked on Waf issues before for community/aubio, i think you can try adding "waf" to makedepends, removing the vendored waf and waflib, then symlinking /usr/bin/waf into $builddir, and see if it'll work 2024-07-03 10:00:12 Hmm, too bad waf 2.1.x switched from optparse to argparse, so as you can see from my patch in community/aubio, you'll need to patch the "wscript", changing `type='string'` to `type=str` 2024-07-03 10:01:58 I think it should work after doing that, and the patch to "wscript" should be smaller than the patch to "waflib" 2024-07-03 10:04:47 cely: OK, thanks for your patch. 2024-07-03 10:04:50 We will refer to your patch in loongarch64 to verify whether it works. 2024-07-03 10:05:07 and from what i see, this is a Python 3.12/Waf issue, which affects all archs, the commit message probably shouldn't be "fix build on loongarch64" 2024-07-03 10:07:09 ncopa: Regarding alpine-keys, maybe can consider cely's suggestion, I think it's good 2024-07-03 10:08:41 cely: Yes this is a problem for all arches, will modify update comment message 2024-07-03 10:10:37 ikke: who has the authority to help add topics to this channel? To be honest, I am not very familiar with irc. 2024-07-03 10:11:55 Channel operators (those with @ in front of their nicknames) can set the topic 2024-07-03 10:14:46 Unless the channel is -t (this channel is not), then anyone can set the topic 2024-07-03 11:04:29 I can't seem to find Channel operators, this channel was originally created with the help of clandmeter,maybe I can't set it up 2024-07-03 11:05:04 clandmeter: we would appreciate it that if you has time to help create topics:-D 2024-07-03 13:39:37 huajingyun: did you register your nickname? 2024-07-03 13:40:38 I think not 2024-07-03 13:41:00 It seems huajingyun's nickname is not registered 2024-07-03 13:42:09 right 2024-07-03 13:42:13 thats what im getting :) 2024-07-03 13:44:52 From what i remember, registering with NickServ requires solving a captcha at https://services.oftc.net/ so make sure you are able to access that 2024-07-03 13:45:53 The email provided to NickServ is not verified (verification is through captcha i mentioned above), and i think only used if you forget your password 2024-07-03 13:47:26 Wow, i happened to look at build.a.o now, and it seems PicoLisp builds on Loongarch (with a lot of warnings though), i was not expecting that 2024-07-03 13:47:50 It doesn't even build on riscv64 2024-07-03 13:48:19 algitbot: retry master 2024-07-03 13:55:40 iirc nickname could be registered from irc client on OFTC 2024-07-03 13:56:05 but I forgot, time passed when I did this 2024-07-03 13:57:18 Yes, it is registered through IRC, but you need to do the captcha verification step 2024-07-03 13:58:15 Otherwise let's say the channel only allows verified nicknames to speak, you can be registered (and identified), but if you didn't verify through captcha, you can't speak 2024-07-03 13:59:01 Maybe earlier on this (one-time) verification was done by some other means 2024-07-03 14:00:24 I can't remember I had to solve any captcha 2024-07-03 14:02:38 Yes, so probably things were done differently when you registered 2024-07-03 14:02:50 huajingyun: /msg NickServ help register 2024-07-03 14:02:56 Will tell you what you need to do 2024-07-03 14:03:59 The "link that expires in 1 hour" is what i was referring as captcha verification through https://services.oftc.net 2024-07-03 14:10:17 After you have registered, depending on what IRC client you use (i think you've mentioned before that you use Pidgin?), there may be options to auto-identify to NickServ whenever you (re)connect, or else if can be done manually through /msg NickServ identify 2024-07-03 14:10:27 s/if can/it can/ 2024-07-03 14:11:06 but from what you don't reconnect that often, so it's probably fine 2024-07-03 14:11:23 from what i see* 2024-07-03 14:18:32 huajingyun: As you've been given channel operator status (+o), the NickServ thing is mainly for "reserving" your nickname so others can't use it, and for getting you +o automatically if you reconnect 2024-07-03 14:23:49 A lot of KDE aports are now failing on build-edge-loongarch64 due to "dbus-daemon-launch-helper" having a bad signature 2024-07-03 14:53:18 Oh no, Go rebuilds have started, so this will be a test of the Loongarch builder 2024-07-03 15:15:03 a test? 2024-07-03 15:15:21 The Loongarch builder is now online 2024-07-03 15:15:29 and is now working on the Go rebuild 2024-07-03 15:17:59 cool ^^ may have initially misunderstood to mean there was something specific with go that makes it a test 2024-07-03 15:21:09 I think it is mostly Go that is followed by a rebuild, for almost every upgrade 2024-07-03 15:21:25 So it is a test :) 2024-07-03 15:21:36 it's not connected yet to the ci pipeline? still exciting news, so close 2024-07-03 15:21:54 As far as i know, the builder is online, but CI is not 2024-07-03 15:23:00 true, a test of rebuilding all the go things 2024-07-03 15:25:15 then the rust packages? ^^ 2024-07-03 15:26:32 From anecdotal evidence, a Perl (only aports linked to libperl.so) rebuild takes about 6 hours, an OCaml rebuild 3, Go will take about a day 2024-07-03 15:26:48 I think Rust may take a week 2024-07-03 15:27:29 ACTION needs to work on CI 2024-07-03 15:27:50 Must...be..faster than Rust 2024-07-03 15:29:37 lol ... it's more a reflection of the number of packages from each of those ecosystems that have been added to alpine? 2024-07-03 15:29:59 so lots of go and rust packages, they take longer? 2024-07-03 15:30:52 That may be a part of it, but it is a fact that Rust is not fast :) 2024-07-03 15:33:58 ^^" ghc 2024-07-03 15:35:09 ACTION is now interested in what Haskell aports mio has worked on 2024-07-03 15:35:13 I think go has (or had) more packages 2024-07-03 15:36:08 ACTION laughs and shakes head 2024-07-03 15:36:18 was just thinking of pandoc 2024-07-03 15:36:44 ikke: yeah, there seems to be a lot of those 2024-07-03 15:40:49 is the ci more or less the same process as the other arches, or are there particular considerations for loongarch? 2024-07-03 15:40:59 the setup, that is 2024-07-03 15:41:22 well, one thing that does not help is that there is no alpine:latest yet 2024-07-03 15:41:36 (ie, alpine image) 2024-07-03 15:41:43 so that means all images need to be built by hand locally 2024-07-03 15:42:24 and high latency + slow download speed does make that a bit harder 2024-07-03 15:43:37 was that different from bootstrapping riscv64, the image had to be built as well back then? 2024-07-03 15:43:43 ouch, yeah, latency 2024-07-03 15:44:19 rv64 was different for other reasons: we had no native hardware 2024-07-03 15:44:34 but the docker image was at least already there 2024-07-03 15:45:50 ah, manufacturer supplied a docker image or ...? 2024-07-03 15:46:02 no, but docker itself already had hw to build the images 2024-07-03 15:49:24 does the current builder process help towards bootstrapping an image? 2024-07-03 15:50:58 i.e. it's mostly waiting on that 2024-07-03 15:51:56 it's been interesting watching the process, not every day new arches get added ^^ 2024-07-03 15:53:15 There already is a minirootfs 2024-07-03 15:53:29 so it's basically waiting until docker can officialy provide it 2024-07-03 15:56:32 cool 2024-07-03 15:56:49 But I'll try to already setup CI before that 2024-07-03 15:58:30 straight to native hardware enabled or will there be a transition period of manual triggering a build like riscv64 initially? 2024-07-03 15:58:48 or was the latter only because no native hardware at the time 2024-07-03 15:58:50 Native 2024-07-03 15:59:01 nod, at least nothign with enoug performance 2024-07-03 16:00:58 great ^^ 2024-07-03 16:07:15 (a bit offtopic, haven't forgotten about xrdp, figured will wait until next abump to claim in the same MR) 2024-07-03 16:08:18 yeah, sure, no hurry 2024-07-03 16:08:47 only xrdp, right? xorgxrdp (the drivers) are already taken care of? 2024-07-03 16:09:01 yes, that's still maintained (I assume ;)) 2024-07-03 16:09:15 lol okay, good 2024-07-03 16:13:21 Wow, that means a big portion of the Mate aports (same maintainer as xrdp) are also unmaintained 2024-07-03 16:14:33 had a quick glance while looking up xrdp, only a few of them have gone stale? 2024-07-03 16:14:55 but yeah, sounds like only a matter of time then 2024-07-03 16:15:52 Probably maintained by developers 2024-07-03 16:16:33 Don't know, don't use Mate, even the MR for LXQt 2.0 is from what i see, stagnant 2024-07-03 16:27:06 could keep an eye on a few of them and abump until they find new maintainers. not a mate user either, would be less likely to notice if the gui apps were buggy if not actually using them 2024-07-03 16:29:15 I don't like to touch pkgs I don't use (so I should remove me as maintainer from about one third of pkgs where I'm maintainer :) ) 2024-07-03 16:29:54 lol are you parting with some of your treasures? 2024-07-03 16:30:10 no 2024-07-03 16:30:45 I upgrade and test pkgs just because once upon I accepted to be maintainer 2024-07-03 16:31:15 lol good ... you already gave away a precious timg ^^ 2024-07-03 16:31:16 but I feel this is not good 'workflow' 2024-07-03 16:32:50 yes, I gave some pkgs when someone more competent than me want to maintain or someone competent want to take maintainership (ZIG is one example) 2024-07-03 16:33:26 but I can't find anyone competent for linux-edge ;-) 2024-07-03 16:33:45 yeah, that is one of my hesitation about taking up packages. guess on a balance of probability a package is stable, wouldn't mind, but gui app behaviour don't always get fully covered by tests 2024-07-03 16:34:30 and if not actually using it, would be less likely to tell if there is an issue until someone reports it 2024-07-03 16:34:31 mio: right, especially these big DEs 2024-07-03 16:34:59 lol that's because linux-edge already has a good home 2024-07-03 16:35:41 yes, I try to keep it in sane state 2024-07-03 16:36:07 Hmm, no wonder there are so many GUI-related teams: team/kde team/gnome team/phosh team/alpine-desktop team/x11-wayland 2024-07-03 16:36:15 (so did timg, frankly, but sometimes out with the old so there's room for the new) 2024-07-03 16:36:55 I even forgot that I gave timg 2024-07-03 16:38:34 lol the sign of someone with a large collection of treasure 2024-07-03 16:38:41 actually I want to use free time on more specific kernels for particular SBCs and arches 2024-07-03 16:39:10 and specific tools for such things 2024-07-03 16:39:54 I think next thing will be to add loongarch to linux-edge or create linux-loongarch64 2024-07-03 16:40:53 rewrite linux-gru to linux-rockchip maybe and linux-elm to linux-mediatek 2024-07-03 16:41:29 hope linux-starfive will be retired with kernel 6.11.x 2024-07-03 16:42:39 maybe add loongarch to u-boot 2024-07-03 16:44:58 cely: guess it makes sense to form teams to maintain, gnome alone has a decent-sized suite of apps that seem to be added and dropped every now and then 2024-07-03 16:45:34 Probably 2024-07-03 16:49:52 there already are teams 2024-07-03 16:50:44 mps: ones like linux-startive are retired because they have been mainlined, or ...? 2024-07-03 16:50:49 maybe I misunderstood what was being discussed 2024-07-03 16:51:08 Yeah, we weren't discussing starting teams for the GUI aports 2024-07-03 16:51:09 ikke: yeah, sorry, should have clarified that was maybe why the teams were formed ^^ 2024-07-03 16:51:34 s/startive/starfive/ 2024-07-03 16:51:46 ikke: PCI will be merged to 6.11 probably so all will in mainline 2024-07-03 16:51:55 that would be nice 2024-07-03 16:51:58 will be* 2024-07-03 16:54:59 (OT, I wait when all asahi things will be mainlined) 2024-07-03 16:55:43 how long have you been waiting? 2024-07-03 16:56:08 mio: more than 2 years iirc 2024-07-03 16:57:55 is that common? vaguely recall odroid-c2 look at least a year back then, with community devs helping 2024-07-03 16:59:03 mio: I didn't noticed any rules for such things. some are ready 'from the start' and some never 2024-07-03 16:59:43 but the manufacturer is a relatively small company, so don't know what is considered a standard timeframe for the process 2024-07-03 17:00:02 nods 2024-07-03 17:09:35 mio: depends of manufacturer stance to open source 2024-07-03 17:09:53 for example starfive was very good 2024-07-03 17:10:39 while mediatek was example of bad, not to mentioned 'ugly' broadcom 2024-07-03 17:10:59 s/mentioned/mention/ 2024-07-03 17:11:28 looks like loongsoon is good 2024-07-03 17:15:30 yeah. guess some are okay, but the process may take longer if it's the first time going through the process, or the smaller ones that can't spare a lot of dev cycles yet 2024-07-03 17:16:07 e,g. odroid-c1 never got mainlined, sadly 2024-07-03 17:17:27 ACTION liked the raspberry pi 3 era of similar-style sbcs 2024-07-03 17:19:20 now we have riscv SBCs so I don't look at new arm boards 2024-07-03 17:20:06 I have some interest to loongarch because I liked MIPS 2024-07-03 17:23:29 have riscv sbcs caught up in overall performance yet? also interested in a riscv sbc eventually, if any with a similar form factor/style as a pi, but so far haven't heard of any yet where cpu performance was nearly as good 2024-07-03 17:24:06 as say, an odroid-c4 2024-07-03 17:24:50 mio: starfive VF1 and VF2 have GPIO header compatible with RPIs 2024-07-03 17:25:36 both are very stable in our (alpine devs) tests 2024-07-03 17:26:41 and we got two Milk-V Pioneers for alpine development 2024-07-03 17:28:51 thanks, will look up the starfives ^^ ... +1 the ones that are mainlined, usually means better long-term support 2024-07-03 17:29:46 u-boot for starfive is mainlined 9-10 months ago 2024-07-03 17:30:03 starfive V2 2024-07-03 17:30:55 all except PCI drivers is mainlined somewhere in october or november previous year 2024-07-03 17:33:00 and they have already posted a lot to kernel and u-boot for their new JH8100 SoC which is not yet on the market afaik 2024-07-03 17:33:29 wonderful 2024-07-04 01:33:48 Hi all,thanks for your comments:-D 2024-07-04 01:34:02 The account huajingyun should be fine. I remember registering and passing the email verification at the beginning. 2024-07-04 01:35:04 You may be thinking of something else 2024-07-04 01:35:29 As i said IRC NickServ registration doesn't involve email verification 2024-07-04 01:35:51 might be another network? 2024-07-04 01:35:54 Anyway, you can sort that out later on, now you've already been given +o, and can use the /topic command 2024-07-04 01:36:40 e.g. libera.chat doesn't have the captcha step, uses email verification code 2024-07-04 01:37:03 but glad it's sorted ^^" 2024-07-04 01:37:39 Yeah, iirc Jingyun originally thought this channel was on Libera 2024-07-04 01:39:22 yeah, both networks host a lot of foss projects 2024-07-04 01:42:46 offtopic question, is it okay to update the mate-* packages piecemeal in separate MRs or do reviewers prefer a set in one MR approach? was checking the MR history on gitlab, they're almost all updated separately, but then there's mate-desktop-environment meta package, would that break while there's a mix of packages in different versions? 2024-07-04 01:43:21 yeah, i may have mixed it up,it's been too long 2024-07-04 01:43:31 but it looks like it should be fine now, do I still need to reconnect 2024-07-04 01:43:40 No 2024-07-04 01:45:11 Ok,thanks 2024-07-04 01:45:27 mio: i'm not sure about that, but i think if anyone reviewing the MATE MR prefers them in separate MRs they will leave a comment on your MR telling you that 2024-07-04 01:46:02 Sometimes i've seen multiple related aports being updated one after another in separate MRs, and wished they were not separated 2024-07-04 01:46:43 okay. just got things started with one MR containing -common and -desktop, wasn't sure if reviewers find it more tedious to review one large MR vs. a bunch of smaller MRs 2024-07-04 01:46:44 so you know my preference, but i'm not sure if i should review the MATE MR, as i don't use MATE, sorry 2024-07-04 01:47:14 If the changes are mostly just version bumps, then i think everything in one MR is alright 2024-07-04 01:47:23 okay, thanks for letting me know your preference, it's helpful feedback ^^ 2024-07-04 01:48:53 okay. yeah, so far they seem to be mostly version bumps. if that's no issue then will try for one MR that includes all the ones in the meta-package, to avoid mixed versions potentially breaking the meta-package 2024-07-04 01:50:59 not currently a mate user ^^" was looking at the mate desktop website and right under the release news, it lists all the os where mate is available, alpine being at the top of the list (alphabetical order) 2024-07-04 01:52:23 just thought it would be good if alpine's were updated to the latest version ^^" 2024-07-04 01:53:43 Ok, so thanks for working on that, hopefully you will get some reviewers for the MR 2024-07-04 01:54:33 If it just sits there for a few weeks, then maybe you will have to start actively looking for some reviewers 2024-07-04 01:56:32 thanks ^^ 2024-07-04 01:57:14 You're welcome 2024-07-04 03:28:15 Wow, i think anitya (pkgs.a.o/flagged) was down for a few days, so now there is about 3.5 pages of flagged aports 2024-07-04 03:35:25 and now someone has flagged musl with the message "The release number is starting at 0, not 1 as indicated in the package information." 2024-07-04 03:47:00 anything fun in the update? 2024-07-04 03:47:33 or at least interesting among the new flags 2024-07-04 03:51:24 hehe 2024-07-04 03:51:44 I'm not sure, i was enjoying the relatively silent pkgs.a.o/flagged 2024-07-04 03:52:08 So now i just skimmed the 3.5 pages and picked a few that jumped out at me 2024-07-04 03:52:11 lol 2024-07-04 03:55:26 guessing it's not electron 2024-07-04 03:57:14 besides perl obviously, which one? 2024-07-04 03:57:49 cosmopolitan looks interesting, but probably not going to make it easy 2024-07-04 03:58:31 Perl is flagged wrongly 2024-07-04 03:58:48 It follows the odd-development, even-stable versioning scheme 2024-07-04 04:00:01 til ... anitya doesn't have a way of filtering for that? 2024-07-04 04:00:35 It probably does, but i've never looked deeper into anitya 2024-07-04 04:00:52 a number of projects follow a similar odd/even versioning scheme 2024-07-04 04:01:44 ah well, guess maintainers can filter locally on their end 2024-07-04 04:04:53 :) 2024-07-04 04:54:58 The number of aports enabled for Loongarch in community/ has increased from 5888 to 5891 2024-07-04 05:18:51 steady progress 2024-07-04 05:19:36 One of that must be your community/barcode 2024-07-04 05:21:13 lol was just about to say thanks for merging that ... Weijie Wang patched it 2 weeks ago, decided to keep it instead of drop 2024-07-04 05:21:49 As always, you're welcome 2024-07-04 05:23:03 since someone took the time to patch, and maybe it's one of those niche things that is either not much use, with zint already in the repos, or very useful when a use case arises 2024-07-04 05:24:11 ^^ ... would have waited until next abump but it rarely ever updates lol 2024-07-04 05:26:05 does that mean anything that gets moved from testing->community from now on will automatically get uploaded to community for loongarch? 2024-07-04 05:26:34 only main/ and community/ ? 2024-07-04 05:26:55 or is testing/ already uploading as well 2024-07-04 05:34:57 I think ikke just merged your MATE MR 2024-07-04 05:35:38 community/ is blocked 2024-07-04 05:36:13 The Go rebuilds encounter network issues quite often due to having to download Go modules 2024-07-04 05:36:39 and there is very likely still MRs open for the Go aports that maintainers have not responded to 2024-07-04 05:37:13 So, i am not expecting build-edge-loongarch64 to proceed onto testing/ for some time 2024-07-04 05:37:52 Btw, the builder now uploads to dev.a.o/edge 2024-07-04 05:38:37 to allow Jingyun to continue uploading to dev.a.o/~loongarch/edge without conflicting with the builder 2024-07-04 05:39:08 you're right, thanks ikke ^^ 2024-07-04 05:39:28 Probably testing/ in dev.a.o/~loongarch/edge will still be updating, and if so, it'll be more up to date than testing/ in dev.a.o/edge 2024-07-04 05:39:33 s/updating/updated/ 2024-07-04 05:40:29 cool ^^ they'll be synced up later in terms of patches or ...? 2024-07-04 05:41:37 Yes, they'll sync up eventually, not sure what you mean by "in terms of patches" 2024-07-04 05:42:06 Anyway, to answer your question, anything moved from testing->community now will be added to the "aports total" count on build.a.o 2024-07-04 05:42:30 but as community/ is blocked on the Go rebuilds and other things, it'll be a while before dev.a.o/edge can be updated 2024-07-04 05:43:12 The builder waits for everything to build successfully first, before uploading the .apks 2024-07-04 05:44:00 That comes in useful for example in pkgrel bumps for soname changes 2024-07-04 05:44:24 If the rev bumps are all committed in one go, that is 2024-07-04 05:46:50 okay. by patches just meant if they were using ~loongarch/edge for testing purposes on updates, if those changes would eventually be brought back to dev.a.o/edge via regular MRs 2024-07-04 05:47:46 nods, so still blocked on some core dependencies 2024-07-04 05:49:52 Of course all patches will have to eventually end up in aports, to allow the builder for 3.21 to build everything from scratch (when it does come online) 2024-07-04 05:52:35 As for whether ~loongarch/edge is for testing purposes, i think it's more just to have a place with updated aports while the builder works through community/ (and cannot upload the new versions until all aports build successfully) 2024-07-04 05:55:53 sounds good. what happens to open MRs for go aports with no maintainer response, do they eventually get merged or ...? 2024-07-04 05:56:32 before/after the 1-month stale tag 2024-07-04 05:56:59 Hahaha 2024-07-04 05:57:26 That depends on who is brave enough to merge them 2024-07-04 05:59:06 I think sooner or later we'll need to think of something, either the silence is taken to mean that don't agree with those changes, and the aports just get !loongarch64 (which hopefully shouldn't require additional maintainer approval) 2024-07-04 05:59:15 s/that/they/ 2024-07-04 05:59:41 or someone review those changes and accepts them on behalf of those maintainers 2024-07-04 06:02:24 lol okay ... wasn't sure if there was already a precedent set from enabling riscv64 2024-07-04 06:02:54 I think due to the issue of maintainer silence, and some disagreement on whether pkgrel needs to be bumped, quite a number of Rust aports that could've been enabled by updating the libc crate have now gotten !loongarch64 instead 2024-07-04 06:03:37 while the Loongarch team works to get that libc crate update upstreamed, and then re-enable Loongarch with a more straightforward (at least to me) version upgrade 2024-07-04 06:07:27 yeah, upstreaming would make more sense 2024-07-04 07:00:22 nice, loongarch is mostly RISC and von Neuman type (I can't remember when was last time I saw 'harward' type of new CPU) 2024-07-04 07:02:26 (last somewhat harward like CPU was NC4004/NC4016/RTX2000, which I played with short time) 2024-07-04 07:20:53 I have never seen one 2024-07-04 08:10:48 NC4004/NC4016/RTX2000 (forth CPUs) are not full harward but they have separate program memory, separate return stack and separate data stack. even separate I/O address bus 2024-07-04 08:11:29 separated by address and data bus 2024-07-04 08:12:07 not fully though. maybe it could be called hybrid of harward and von Neuman 2024-07-05 01:01:23 cely: py3-tika will be disabled on loongarch64, can you help merge this MR? !68762 2024-07-05 01:01:29 It is not assigned to anyone 2024-07-05 01:11:23 Hello 2024-07-05 01:11:46 It seems the comment regarding the reason was added earlier on? 2024-07-05 01:13:12 yeah, sorry, this was an omission, I just discovered it 2024-07-05 01:15:55 zhaixiaojuan just submitted a new MR, py3-tika blocked the builder 2024-07-05 01:16:05 Alright, i will take care of that shortly 2024-07-05 01:16:38 Thanks 2024-07-05 01:17:51 You're welcome 2024-07-05 01:26:47 Ok done 2024-07-05 01:29:00 huajingyun: i think the abuild process for py3-tika will still have to manually terminated, otherwise the builder will continue to be blocked 2024-07-05 01:30:39 Yes 2024-07-05 04:29:38 It's been a quiet day so far.. 2024-07-05 06:12:59 A bit busy, there is no independent abuild process for py3-tika 2024-07-05 06:13:05 unless we terminate the buildrepo process 2024-07-05 06:14:22 Probably that's what should be done 2024-07-05 06:14:32 I think it will just start over after a "retry master" 2024-07-05 06:19:55 There should be an abuild process 2024-07-05 06:20:51 Anyway, the error message has showed up in #alpine-commits 2024-07-05 06:20:58 algitbot: retry master 2024-07-05 06:22:49 Yes, I have just done it, it seems to have been retriggered 2024-07-05 06:23:45 ikke: yes,terminated the abuild process 2024-07-05 06:24:14 That means abuild does not get to clean up 2024-07-05 06:24:40 Can you verify there are no .makedepends are left in /etc/apk/world 2024-07-05 06:27:03 only .makedepends-openssl=20240705.062109 2024-07-05 06:27:19 That's currently building 2024-07-05 06:28:03 It looks like no py3-tika related packages are left 2024-07-05 06:30:25 Maybe you can check for /usr/bin/python*, i think openssl doesn't use that (unless there is something else that uses it) 2024-07-05 06:32:15 Currently only these packages are installed in /etc/apk/world, .makedepends-openssl=20240705.062109,abuild,abuild-sudo,alpine-base,openssh,pigz 2024-07-05 06:32:41 Ok 2024-07-05 06:33:19 yeah, there is no /usr/bin/python* 2024-07-05 06:35:18 ikke: Usually, when you find a problem like this, how do you deal with it? 2024-07-05 06:35:37 I use htop, with the treeview 2024-07-05 06:36:22 Then select the top most process directly under abuild, press c to select that process with all child processes and kill them 2024-07-05 06:38:51 Oh, nice 2024-07-05 06:39:26 Thanks 2024-07-05 06:43:08 !68784 contains an almost 3MB patch, i think that's probably too big 2024-07-05 06:44:51 Yeah, definitely 2024-07-05 06:55:09 Just confirmed that this loongarch64 patch can be reduced to 6.5k lines. Is this acceptable? 2024-07-05 06:56:32 Or we can temporarily disable it on loongarch64 and wait for upstream 2024-07-05 06:57:29 That may be better 2024-07-05 06:57:54 Any idea why wasi-libcxx is now failing as it can't find pthread.h? 2024-07-05 07:00:25 Wait, let me see. 2024-07-05 07:20:33 znley: It's unicorn not unicron (!68789) 2024-07-05 07:21:43 I rebuilt wasi-libcxx locally which is fine,but see that wasi-sdk in aports is rebuilt based on llvm18, maybe it has something to do with this, I am rebuilding them 2024-07-05 07:22:59 Ah, so the wasi-sdk currently in repo was built against llvm17? 2024-07-05 07:24:04 Wait, but i don't think it uses wasi-sdk 2024-07-05 07:24:40 Ah, i guess you mean you are rebuilding both wasi-libcxx and wasi-sdk 2024-07-05 07:24:49 yes 2024-07-05 07:27:27 aports just merged this in the past two days: main/wasi-sdk: build for llvm 18 and main/wasi-libcxx: rebuild with wasi-sdk-22 2024-07-05 07:27:57 Ok 2024-07-05 07:28:20 Ok, changed it, maybe english have a little difficult for me. 2024-07-05 07:28:39 btw, patch in !66680 could be avoid, upstream has updated libc's version 2024-07-05 07:28:50 https://github.com/extrawurst/gitui/blob/v0.26.3/Cargo.lock#L1290 2024-07-05 07:30:44 Ok, so i guess you're suggesting to turn it into an "upgrade to 0.26.3" MR 2024-07-05 07:31:21 yes :) 2024-07-05 07:31:53 qaqland: Ok, thank you, we will update this MR, upgrade to 0.26.3 2024-07-05 08:36:00 I see more Loongarch team members have joined this channel 2024-07-05 08:36:03 Welcome 2024-07-05 09:10:45 Yeah, zhangwenlong and zhaixiaojuan joinedthis channel today 2024-07-05 09:12:19 I'm really happy to join this channel and look forward to learning and making progress with everyone 2024-07-05 09:14:00 Hello :) 2024-07-05 09:15:30 Hi:) 2024-07-05 09:15:49 huajingyun: Just checking, you all don't check IRC during weekends, right? 2024-07-05 09:36:52 yes, we usually only work here one weekend a month, for example, we will be here tomorrow 2024-07-05 09:38:46 Ok 2024-07-05 09:39:24 unless there is something important 2024-07-05 09:41:13 Alright, just wondering if you can spare a few minutes 2024-07-05 09:42:11 May want to ask something (with my other nickname) 2024-07-05 09:43:34 Ok,no problem:) 2024-07-05 12:40:35 welcome new participants ^^ 2024-07-05 12:41:45 ikke: for !68751 the other 3 packages that need rebuilding can be added to the same MR? 2024-07-05 12:43:57 they were going to be upgraded in another MR with the rest of the mate-* packages, mate-screensaver is in a pending MR with 4 other mate packages maintained by another person 2024-07-05 12:47:04 huajingyun: you didnt update the topic ;-) 2024-07-05 12:48:27 to confirm, will add the 3 mate-* packages to this MR ... and adjust the other draft MR accordingly. if that's not quite right, please let me know then and will readjust ^^" 2024-07-05 12:48:50 mio: those packages would be broken until they are rebuilt 2024-07-05 12:49:29 So that's why rebuilds are expected to be in the same MR 2024-07-05 12:50:18 If something would prevent them from being built, that would show up in CI 2024-07-05 12:52:05 okay ... but generally the ci will be able to detect the order of dependencies? sort of separated the core packages to ensure the rest of the mate-* packages will build on new ones instead of older, but maybe that is not the best idea then 2024-07-05 12:52:58 Yes, the CI will order everything correctly, just like the builder does 2024-07-05 12:52:59 i.e. better to use the command in your comment to see which depends on the so and upgrade those in the same MR instead 2024-07-05 12:55:51 okay, thanks ikke and cely ^^ is there currently a backlog for riscv64 packages? the mate-desktop package for riscv64 hasn't made it to pkgs.a.o listing yet, hope didn't do something wrong there 2024-07-05 12:56:21 As shown on build.a.o, riscv64 is blocked on filebrowser 2024-07-05 12:56:38 Which is an aport needing npm to build 2024-07-05 12:56:57 I think i've noticed npm failing on riscv64 for quite a few aports 2024-07-05 12:57:47 did anyone wrote how to run loongarch64 alpine under qemu 2024-07-05 12:58:33 I don't think so 2024-07-05 12:59:04 ok, will try then 2024-07-05 12:59:43 okay, thanks. however, it means the libmate-* MR might fail on riscv64 with the other 3 mate-* MRs added 2024-07-05 12:59:45 That would be good to read about, thanks :) 2024-07-05 13:00:35 iirc loongarch pkgs somewhere on dev.a.o? 2024-07-05 13:00:36 If anything was written, i think it would be on wiki.a.o, but last time i checked there, i don't remember seeing anything about QEMU (there is a Loongarch wiki page) 2024-07-05 13:00:52 dev.a.o/edge has packages from the builder 2024-07-05 13:01:07 dev.a.o/~loongarch/edge has packages manually uploaded by huajingyun 2024-07-05 13:01:35 (Now my internet seem to have gone crazy again, and i can't access wiki.a.o) 2024-07-05 13:01:44 cely: thanks for info 2024-07-05 13:01:47 pkgs.a.o is also slow for me 2024-07-05 13:01:50 You're welcome 2024-07-05 13:01:53 Though gitlab.a.o is fine 2024-07-05 13:02:34 mio: Did you find out what issue riscv64 is seeing? 2024-07-05 13:03:29 I think some change made after 3.20-stable was released is causing problems on riscv64 (but i can't seem to pinpoint what it is) 2024-07-05 13:06:06 not sure what you meant by issue? ^^" it's just that a few mate-* packages have a version check for mate-desktop >= 1.27, so they will fail build until the risv64 mate-desktop 1.28 package is live 2024-07-05 13:06:23 Ah! 2024-07-05 13:06:30 but don't know what is wrong with riscv64 builder itself ^^" 2024-07-05 13:06:42 if anything 2024-07-05 13:07:04 I think that is fine, during the Python 3.12 rebuild, CI was also read for riscv64 for sometime while it caught up 2024-07-05 13:07:15 CI for Python aports, that is 2024-07-05 13:07:26 guessing normally mate will still update okay, but the mate packages have been too old 2024-07-05 13:07:43 jumped from 1.26 -> 1.28 2024-07-05 13:08:00 How many packages does it need for CI to be green? 2024-07-05 13:08:38 I mean, how many packages need to be at version 1.28? 2024-07-05 13:09:12 If it's just one or two, you can revbump them in the MR and verify that CI is green, then remove them afterwards 2024-07-05 13:11:50 guesing 1-2, mate-desktop-dev for sure, and maybe marco-dev 2024-07-05 13:13:11 but marco-dev isn't pushed in yet, will probably add it to the same MR as well as a dep of mate-control-center (one of the 3 mate-* packages that need rebuilding that i k k e mentioned) 2024-07-05 13:13:18 Anyway, you can do what i said above, to check if CI is green, or just wait for the riscv64 builder (MATE is in community/, so it should build the next time riscv64 is retried (it's now stuck on testing/)) 2024-07-05 13:14:19 thanks for the advice. will wait then ^^ not seeeing anything in particular that would prevent them from building in riscv64 specifically 2024-07-05 13:14:35 other than waiting for the updated lib 2024-07-05 13:17:56 not in a hurry to have them go through as long as someone can check them eventually before the next relase lol ^^ 2024-07-05 13:18:07 I think in general, for things like MATE, you should just upgrade everything in one MR 2024-07-05 13:18:17 Just like the LXQt 2.0 MR does 2024-07-05 13:19:08 That is blocked on maintainer feedback, when i looked at it when that MR was opened, i felt it was ready to merge 2024-07-05 13:19:44 but gave the maintainer time to respond, unfortunately, that response turned out to be a "wait" 2024-07-05 13:19:49 and so, we have been waiting until now 2024-07-05 13:19:57 s/relase/release/ ... yeah, starting to think that may have been better, but also wasn't sure if that would make it more difficult for maintainers of packages to wade through 2024-07-05 13:20:38 most of these are by the original maintainer of xrdp, but 5 of them are maintained by another person 2024-07-05 13:21:11 You can always @-mention the other maintainers and ask if the changes for their aports are okay 2024-07-05 13:21:15 thought it would be easier if they didn't have to sift through the other 20+ packages, though could just list theirs 2024-07-05 13:22:12 No problem, now you know what can be done better next time 2024-07-05 13:23:01 I think the MATE aports should be consolidated under a single maintainer, though hopefully that maintainer is an active one, and so it won't be like LXQt where we have no idea how long we will be waiting for 2024-07-05 13:23:03 mio: trivial updates and pkgrel bumps are easy to verify 2024-07-05 13:23:42 true. at this point will probably close the other MR with the maintainer's 4-5 packages and put them in one ... though did wonder about the packages list in the metapackage, some key apps in MATE aren't listed there, like atril 2024-07-05 13:24:36 guessing there was a reason for that but don't know if it's documented somewhere which ones were included/why 2024-07-05 13:25:37 ikke: okay, good to know ^^ mate-control-center does need a temporary patch to build, will highlight that in the MR 2024-07-05 13:26:06 MR description that is. temporary as it's in upstream master but after this release, so backported 2024-07-05 13:29:14 so the ones that aren't in the metapackage was thinking of putting in another MR (3: atril, engrampa, eom), unless people think they should be added to the metapackage list? 2024-07-05 13:33:00 or could add those in the MR anyway even if not technically in the metapackage (they are featured on the MATE website) 2024-07-05 13:34:57 I think you can decide what to do, after all 3 additional aports is probably not going to add a significant review burden 2024-07-05 13:35:20 especially if it's just pkgver upgrades (no additional patches needed) 2024-07-05 13:55:34 all-in-one it is then ^^ and yeah, noted for next time. would be good though if there was someplace or a corner of the wiki where some of it could be documented, for another person that comes along who would like to help maintain the suite 2024-07-05 13:56:42 Maybe you don't have to wait too long for that, there's already !68799 backporting the upgrade to 3.20-stable 2024-07-05 13:57:16 Not sure if such backports are in line with our no breaking changes in stable branches policy though 2024-07-05 14:03:46 ACTION spoke too soon lol 2024-07-05 14:04:22 would it be feasible if that MR included everything in one go, after a brief period of testing in edge? 2024-07-05 14:05:52 don't know what the precedent is for backporting DEs like gnome to stable 2024-07-05 14:07:20 Rarely happens 2024-07-05 14:08:46 not thinking of doing it, just wondering if the policy would allow if someone was interested, since it is 10+ packages and not 1 small thing 2024-07-05 14:09:35 nods 2024-07-05 15:08:28 mio: it all depends on the impact 2024-07-05 15:08:38 Both for us as for the users 2024-07-05 15:12:48 commit message could change from "loongarch" to upgrade (!66680) 🤔 2024-07-05 15:13:27 Hehe, qaqland, i remember that you messaged me a few days ago 2024-07-05 15:14:20 ikke: makes sense. guess in this case there might have been a request because it missed 1.27 2024-07-05 15:14:32 Anyway, unfortunately for the gitui MR, i think the chances of it being merged are a bit slim 2024-07-05 15:14:35 cely: yesterday i want to say thanks to you but find you not in alpine-devel 2024-07-05 15:15:16 Thanks for what? :) 2024-07-05 15:15:21 Rustlings? 2024-07-05 15:15:25 yes!! 2024-07-05 15:15:37 Well, appreciation is always appreciated 2024-07-05 15:16:36 Anyway, back to the gitui MR, Jirutka himself has commented on the MR you linked to 2024-07-05 15:16:57 Sorry 2024-07-05 15:17:09 Github issue, not MR 2024-07-05 15:17:23 second what qaqland said, thanks for your advice on the mate process and blanket 2024-07-05 15:18:02 So, i think he is unlikely to approve and merge the gitui MR until gitui upstream takes his concerns into consideration 2024-07-05 15:18:47 likewise ikke, thanks. noted the one-liner command for future reference, waiting for the paint to dry ^^" 2024-07-05 15:18:59 Though of course, trying to get the CI green is always welcome 2024-07-05 15:19:01 haha :D 2024-07-05 15:19:59 but don't set your hopes too high, Rust is full of surprises and frustration 2024-07-05 15:20:24 XD 2024-07-05 15:21:01 Anyway, for !66680, according to what i have seen of Jirutka's preferences 2024-07-05 15:21:19 The commit should be broken into two parts 2024-07-05 15:21:37 First one is "upgrade to 0.26.3" and second "enable loongarch64" 2024-07-05 15:24:42 Maybe all the suggested changes can go into the first commit 2024-07-05 15:25:06 but not sure if it's worth all that effort, considering this aport won't block the builders (as it's "enable", not "disable") 2024-07-05 15:25:39 unless someone at Loongarch is specifically interested in having this aport enabled 2024-07-05 15:48:59 Another thing about the gitui MR, is that it may be dependent on !63296 2024-07-05 15:49:52 I upgraded jujutsu to 0.19.0 today, but i find that it still uses libgit2-sys 0.16.2+1.7.2 2024-07-05 15:50:40 Oh wait, that's what gitui uses too 2024-07-05 15:50:52 At least, gitui 0.26.3 2024-07-05 15:51:39 gitui master is already at 0.17.0+1.8.1 2024-07-05 23:54:03 ran into an issue with hugo dependencies tests in certain arches, not sure whether it's okay to add a $CARCH to disable tests for those arches 2024-07-05 23:54:55 wonder if this might also be a loongarch issue too 2024-07-05 23:56:34 might be wrong in this, the cause appears to be that hugo added tailwindcss support, which in turn bundles a water utility that installs arch-specific builds 2024-07-05 23:59:21 watcher has pre-compiled musl binaries for x86_64 and arm64 only 2024-07-05 23:59:49 which may explain why its tests pass there 2024-07-06 00:01:27 while for other arches that are enabled, this happens https://gitlab.alpinelinux.org/mio/aports/-/jobs/1444702#L1415 2024-07-06 00:04:02 ppc64le and riscv64 arches are already disabled for hugo for failed tests, it might make more sense to disable for the other arches altogether then if this means watcher/tailwindcss won't work even if hugo could be built on those arches 2024-07-06 00:05:17 s/water/watcher/ 2024-07-06 00:05:58 on further thought? ... would like any opinions on the suitable course of action in such a case 2024-07-06 00:08:57 this seems to be the most recent list of supported arches for this watcher module was able to find https://github.com/parcel-bundler/watcher/releases/tag/v2.2.0 2024-07-06 00:21:37 Wow 2024-07-06 00:22:52 First thing i would check is if watcher is already in Alpine repos 2024-07-06 00:23:39 okay .. not in repos 2024-07-06 00:24:48 Then perhaps it could be added :) 2024-07-06 00:25:19 Just like i added "promu" a few Go rebuilds ago (was in late February, i think) 2024-07-06 00:27:01 ... in other words, try to build watcher natively instead of using upstream prebuild binaries and then use the system dep? 2024-07-06 00:27:17 Yes 2024-07-06 00:31:02 lol ... not sure if it's okay, will ... try ^^" 2024-07-06 01:20:57 Hi 2024-07-06 01:21:26 many messages:-D 2024-07-06 01:22:53 :) 2024-07-06 01:25:14 So, how was the wasi-libcxx rebuild from yesterday? 2024-07-06 01:25:29 (It's still failing on build.a.o) 2024-07-06 01:25:44 There is no docs on runing loongarch64 in qemu, and I always get delayed when I try to do it. 2024-07-06 01:28:41 For wasi-libcxx , I refactored some packages locally and found the same error as builder 2024-07-06 01:28:51 but strangely, I built wasi-libcxx in docker for x86_64 and got the same error 2024-07-06 01:33:02 I wonder if it's because of the wasi-libc upgrade 2024-07-06 01:35:44 Anyway, can confirm, wasi-libcxx fails on all archs with the pthread.h error 2024-07-06 01:37:00 Wait, it doesn't fail on riscv64 2024-07-06 01:37:19 So, something must still be un-upgraded on that due to it being blocked 2024-07-06 01:38:54 Where can I see the build log of riscv64? 2024-07-06 01:39:35 The only difference i can see is ncurses and wasi-libc 2024-07-06 01:39:45 Trying with old wasi-libc now 2024-07-06 01:40:21 The CI pipeline i ran: https://gitlab.alpinelinux.org/Celeste/aports/-/pipelines/246126 2024-07-06 01:41:56 ok 2024-07-06 01:42:52 It works 2024-07-06 01:43:05 So, something changed in new wasi-libc that causes wasi-libcxx to fail to build 2024-07-06 01:47:34 I think i see the probable cause, `--sysroot=/usr/share/wasi-sysroot` in C/CXXFLAGS 2024-07-06 01:48:28 Oh wait, there is a /usr/share/wasi-sysroot/include/pthread.h 2024-07-06 01:49:18 I'm checking it out. 2024-07-06 01:49:57 Ugh, i'm getting confused 2024-07-06 01:50:06 There is a /usr/share/wasi-sysroot/include/pthread.h in the old wasi-libc 2024-07-06 01:50:31 New one has moved it to /usr/share/wasi-sysroot/wasm32-wasi-threads/include/pthread.h 2024-07-06 01:59:52 https://build.alpinelinux.org/buildlogs/build-edge-x86_64/main/wasi-libcxx/wasi-libcxx-18.1.8-r1.log 2024-07-06 02:00:00 Why does the builder here also use old wasi-libc 2024-07-06 02:02:24 Because wasi-libc was upgraded after that, and wasi-libcxx has not been rebuilt against the new wasi-libc 2024-07-06 02:03:01 However, the Loongarch builder built wasi-libcxx after the new wasi-libc 2024-07-06 02:03:04 So, it's a matter of timing 2024-07-06 02:09:10 I'm trying something, if it works, i'll push it but not bump pkgrel 2024-07-06 02:09:32 and ptrc and see if it's the correct solution, and bump pkgrel for the other archs if it is 2024-07-06 02:09:43 s/and see/can see/ 2024-07-06 02:10:09 It seems to work 2024-07-06 02:10:47 What are you going to do? 2024-07-06 02:11:06 Add --target=wasm32-wasi-threads 2024-07-06 02:11:25 While building the threaded version, that is 2024-07-06 02:11:45 cmake is invoked twice in wasi-libcxx's APKBUILD 2024-07-06 02:14:27 should only need to add it in the second 2024-07-06 02:14:33 The probability is high that it is the correct solution (or at least very close to it) 2024-07-06 02:14:34 Yes 2024-07-06 02:18:46 Or specify include as include , add a patch 2024-07-06 02:21:52 I think --target is the better way, as the error log says it uses --target=wasm32-wasi 2024-07-06 02:22:15 if target is not specified 2024-07-06 02:26:02 agree 2024-07-06 02:27:49 ptrc: As you're the one who upgraded wasi-libc, please have a look at 906804d7c5456aea31dc1338e94aff776f213333, and if you think it is a good solution, then you can bump pkgrel to rebuild wasi-libcxx against new wasi-libc on all the other archs 2024-07-06 02:28:24 Ok, build-edge-loongarch64 is now proceeding onto community/ 2024-07-06 02:33:14 very nice, thanks 2024-07-06 02:33:51 You're welcome 2024-07-06 02:34:42 Hmm, my commit message said "other archs did not do this", which may not be totally accurate, as i think riscv64 will also build wasi-libcxx against new wasi-libc when it finally gets unblocked from the Go rebuilds 2024-07-06 02:45:15 May I ask if someone can help review this MR, !68484 2024-07-06 02:46:29 py3-wsgiprox build require py3-certauth 2024-07-06 02:48:09 I think we may have to wait for @otlabs for that, as he is maintainer of those aports, and reported the issue upstream 2024-07-06 02:49:06 Personally, i think these 2 aports have inactive upstream, and probably need to be removed, unless someone is able to patch it to work against new py3-openssl 2024-07-06 02:51:54 zhangwenlong: We usually prefer not to disable all checks, especially if they point to some issue in the aport itself (which i think is true in this case) 2024-07-06 02:53:39 So, i think what you are seeing now is inactive upstream (so no patch for new py3-openssl/py3-cryptography from upstream) + busy maintainer (who is unable to promptly look into this issue and decide what to do) 2024-07-06 02:54:37 Those 2 aports are uninstallable right now as they haven't been rebuild against Python 3.12 2024-07-06 02:55:11 So, if i were to take more decisive action, i'd just remove them, but i think we should give @otlabs at least some time to respond 2024-07-06 02:59:53 cely: can sending retry master to algitbot trigger the master build? 2024-07-06 03:01:04 It has retried now :) 2024-07-06 03:01:15 It retries whenever commits are pushed 2024-07-06 03:01:40 As for "algitbot: retry master", you can say that too 2024-07-06 03:01:57 Anyone can 2024-07-06 03:02:25 Ok 2024-07-06 03:03:15 and regarding the indi-3rdparty build failure, you'll probably notice it if you take a second look 2024-07-06 03:03:25 It is actually disagreeing on pkgrel 2024-07-06 03:04:06 The error message says indi-3rdparty makedepends expects libindi-dev=2.0.7-r0, but the repo only contains libindi-dev=2.0.7-r2 2024-07-06 03:04:07 cely: Ok 2024-07-06 03:05:14 It is overly strict, as i said in my commit message, so solution is to use ~$pkgver instead to expect 2.0.7 with any pkgrel 2024-07-06 03:05:24 Haha, I submitted a MR before !68536 2024-07-06 03:06:08 Now that it's fixed, I'll close it. 2024-07-06 03:07:02 Hehe, that helps me, as it means if the maintainer wanted that solution, that MR would be approved instead of just sitting there 2024-07-06 03:09:50 if someone can help review this MR, riscv64 builder fails with the well-known "Unable to synchronize I-cache". !68193 2024-07-06 03:11:00 cely: Yes 2024-07-06 03:12:05 I've closed the indi-3rdparty MR now, with a message stating the reason 2024-07-06 03:12:48 I saw it, thank you 2024-07-06 03:13:22 You're welcome 2024-07-06 03:13:32 Now the builder has returned to rdflib 2024-07-06 03:13:40 which keep failing 2024-07-06 03:16:25 zhangwenlong: Squashed and merged the OpenJDK MR, next time you do the squashing :) 2024-07-06 03:16:52 If you click "apply suggestion" it adds a new commit that needs to be squashed 2024-07-06 03:20:03 cely: Okay, I'll pay attention to it next time 2024-07-06 03:23:37 Any idea how to solve the py3-rdflib failure on the builder? 2024-07-06 03:25:12 I want to disable the check of py3-rdflib, it seems that the network 2024-07-06 03:26:25 I'm not sure that will be accepted 2024-07-06 03:27:26 No easy way of letting the network connections go through? 2024-07-06 03:43:32 Let's try to see if we can fix it first 2024-07-06 03:43:48 zhangwenlong: For !68819, i've made some adjustments to the commit message, i think it is better to link to the docs from the official python.org site 2024-07-06 03:43:56 and more importantly is the commit message style 2024-07-06 03:44:19 We prefer to have a summary in the commit message title, and then the details in the commit message description 2024-07-06 03:45:49 If you look at the CI logs, you'll see that the diff at the bottom shows the old version having files in the "python3.11" directory 2024-07-06 03:45:56 That means it was not rebuilt against python 3.12 2024-07-06 03:46:07 So, the commit message title says that 2024-07-06 03:46:43 and also gives a hint about why it was not rebuilt (compatibility with 3.12 was not fixed until now) 2024-07-06 03:47:27 Any other things are details, and go into the commit message description instead 2024-07-06 03:48:16 Ok 2024-07-06 03:49:38 and lastly, although there is very occasionally some activity from @fab 2024-07-06 03:49:55 He is actually retired from package maintainership 2024-07-06 03:50:11 So, there is probably no point in pinging @fab 2024-07-06 03:52:04 Usually if it is only a pkgrel issue on riscv64, and all the other archs are green, we can just merge it 2024-07-06 03:58:45 algitbot: retry master 2024-07-06 04:03:34 cely: thanks for the wasi-libcxx fix :) imo the only improvement would be if the target is a separate cmake variable, but i don't think so? 2024-07-06 04:03:49 so yeah, a pkgrel bump would probably be needed for other architectures 2024-07-06 04:06:14 You're welcome 2024-07-06 04:07:31 I'm not sure about whether the target can be set as a cmake variable 2024-07-06 04:08:14 yeah, i couldn't find anything meaningful for that, so i'd guess not 2024-07-06 04:08:35 It is after all LLVM, so i expect complicated CMakeLists :) 2024-07-06 04:11:52 ptrc: So, shall i push a "rebuild against wasi-libc 0.20240412" commit, or do you prefer to do that? 2024-07-06 04:13:50 up to you, i don't mind 2024-07-06 04:14:17 I'll do it then, together with temporarily disabling py3-rdflib tests for Loongarch 2024-07-06 04:14:26 as the builder keeps coming back to that 2024-07-06 04:18:14 imho the network tests should be disabled anyway, i can try and do that later today 2024-07-06 04:24:34 huajingyun: i see you're AFK, i've disabled py3-rdflib checks for now, i hope the reason is okay with you 2024-07-06 04:24:53 Hopefully, we don't have to do that for too many aports 2024-07-06 04:31:23 Now there's another issue on the builder, "ERROR: dbus-daemon-launch-helper-1.14.10-r2: BAD signature" 2024-07-06 04:35:10 I think almost all the aports from the KDE upgrade will be failing with that error 2024-07-06 04:49:31 Yes, the bad signature error needs to be fixed soon as the builder keeps returning to pipewire now 2024-07-06 04:58:57 For cargo-edit, it seems !66715 still fails tests 2024-07-06 05:30:39 are nodejs module package names prefixed with "nodejs-"? was looking for an example in aports, the packages are mostly standalone applications rather than a lib 2024-07-06 05:33:03 it's for that watcher module. it builds (at least in x86_64) but still have to test whether it actually works with hugo 2024-07-06 05:34:01 There's node-libpg-query 2024-07-06 05:34:10 So, perhaps the answer is yes 2024-07-06 05:34:29 but there are very few libs packaged for Node.js 2024-07-06 05:35:51 I wonder why build-edge-loongarch64 stops at "uploading packages to main" for such a long time 2024-07-06 05:36:04 I hope it's not re-uploading everything each time that message is displayed 2024-07-06 05:36:16 everything in main/* 2024-07-06 05:38:19 okay. a bit uncertain about this watcher module, got this little message during build: 2024-07-06 05:38:25 npm warn deprecated inflight@1.0.6: This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful. 2024-07-06 05:38:40 That's just tha nature of Node.js 2024-07-06 05:38:44 s/tha/the/ 2024-07-06 05:39:32 lol okay, thanks 2024-07-06 06:05:45 I just got back 2024-07-06 06:05:57 cely: of course, thank you for the update on py3-rdflib 2024-07-06 06:08:49 znley: You might need to look at !66715 2024-07-06 06:15:17 got it 2024-07-06 08:04:18 You're welcome 2024-07-06 08:05:24 Any idea if the "bad signature" error can be solve (probably by deleting the .apk), or do we need to wait for n c o p a? 2024-07-06 08:21:12 No,maybe we should wait. 2024-07-06 08:27:17 !66715 CI is green 2024-07-06 08:32:27 Actually 2024-07-06 08:32:57 There's !68085 2024-07-06 08:34:22 One problem with that is pkgrel needs to be bumped again (due to !68251) and everything squashed 2024-07-06 08:34:46 Why does everyone want to make small changes to main/dbus :D 2024-07-06 08:40:09 znley: Am i right that you fixed !66715 by running `SNAPSHOTS=overwrite cargo test`? 2024-07-06 08:41:10 cely: you mean bad signature on builder 2024-07-06 08:42:02 mps: Yes, i am aware we can bump pkgrel, but i didn't want to do that unnecessary (especially as i don't know if there are other packages involved), but now i see !68251 2024-07-06 08:42:18 i can just tidy that up and merge that 2024-07-06 08:42:25 Sorry 2024-07-06 08:42:28 !68085 2024-07-06 08:42:45 cely: someone will to do this at the anyway 2024-07-06 08:43:08 at the end* 2024-07-06 08:43:40 Yeah, either the person who opened that "update configure flags" MR will do it, or someone else will do it 2024-07-06 08:44:50 cely: !68085? let me look 2024-07-06 08:45:47 though git commit msg is nonsense 2024-07-06 08:45:59 Yes, it was supposed to bump to pkgrel=2, and it did, but !68251 bumped it first 2024-07-06 08:46:05 Yes, commit message will need tidying up, and pkgrel re-bumped 2024-07-06 08:46:37 ah, no. it is multiple commits 2024-07-06 08:46:46 and squashed 2024-07-06 08:47:44 imo, should be closed and create new correct one 2024-07-06 08:50:26 The branch is "firasuke-master-patch-72465", so probably opened from the Gitlab Web UI.. 2024-07-06 08:50:31 I can try to tidy it up 2024-07-06 08:54:31 at least half of MRs are in 'bad shape' and I even don't want to look at them 2024-07-06 08:54:52 some are totally useless 2024-07-06 08:57:07 Yeah, sometimes i get a bit annoyed by some of the "improvement" MRs too 2024-07-06 08:58:48 It's like a teacher taking a red pen and marking our homework 2024-07-06 09:07:25 cely: Yes, I did as you said. 2024-07-06 09:08:43 znley: Ok 2024-07-06 09:13:49 znley: Thanks for putting the comment back in, i was just thinking about that 2024-07-06 09:14:20 I add the patch generation method, it helps me a lot. 2024-07-06 09:15:16 I was going to do that, but I forgot. You reminded me. 2024-07-06 09:15:28 :) 2024-07-06 09:44:08 It seems some of the KDE aports are having issus with 403 Forbidden returned by the mirror chosen 2024-07-06 09:44:50 Maybe DISTFILES_MIRROR should be set so it checks distfiles.a.o (i think the other builders do this) before trying to download it from source= 2024-07-06 09:45:32 issues* 2024-07-06 14:47:38 Constant retrying has brought the number of aports to build in community/ from around 510 down to 470 2024-07-06 14:48:23 When the KDE mirror 403 issue is solved, then that number can go down faster 2024-07-06 14:59:29 and if the "uploading packages to main" step can be made faster, then more aports can be retried without having to wait a few minutes in between retries for that uploading step 2024-07-06 15:00:22 I'm still a bit concerned about that, is it really a network speed issue, or is the whole of main/ being re-uploaded every time 2024-07-06 15:02:29 If everything is re-uploaded, then we'd probably want to fix that before the builder proceeds to testing/, as community/ is much bigger than main/ 2024-07-06 16:16:35 Someone able to verify whether https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/68734#note_419076 passes on loongarch? 2024-07-06 18:12:38 hm, it feels like KDE serves a HK mirror based on physical distance, but they block Chinese IPs? can't reproduce the 403 from any other IP 2024-07-07 01:46:45 That seems to be the case, maybe it would be possible for someone in Loongson to email the mirror admins and sort this out? 2024-07-07 01:47:44 Or maybe, it'll be easier to just set DISTFILES_MIRROR like the other builders do, or just download all the KDE tarballs into /var/cache/distfiles 2024-07-07 03:11:25 I think i see a problem 2024-07-07 03:13:13 The time shown for dev.a.o/edge/main/loongarch64/APKINDEX.tar.gz (looking at the directory listing generated by the web server) is 03-Jul-2024 2024-07-07 03:13:55 Whereas for dev.a.o/~loongarch/edge/main/loongarch64/APKINDEX.tar.gz, it is 06-Jul-2024 2024-07-07 03:14:25 If the builder uploads to dev.a.o/edge, that shouldn't be the case 2024-07-07 03:17:26 and maybe that's why build.a.o shows that "uploading packages to main" takes a few minutes for build-edge-loongarch64 2024-07-07 03:18:47 It keeps uploading packages newer than what it sees on dev.a.o/edge, but those never gets in, so it does that again on the next retry 2024-07-07 03:19:33 and it isn't exactly uploading to dev.a.o/~loongarch/edge either, as dbus is still at r2 on both 2024-07-07 03:23:39 main/unbound is also at r1 for both, though wasi-libcxx is at r2 for dev.a.o/~loongarch/edge, but i think Jingyun was working on that yesterday, so probably it was manually uploaded 2024-07-07 04:54:35 439 aports left to build in community/ now 2024-07-07 07:13:41 432 aports now 2024-07-07 12:14:41 !65996 this mr disable loongarch, but upgrade to 18.3.0 would upgrade linux-raw-sys itself 2024-07-07 12:15:43 here the version is supported: https://github.com/atuinsh/atuin/blob/v18.3.0/Cargo.lock#L1992 2024-07-07 13:10:17 I hope the person who opened !68740 really understand what they're doing 2024-07-07 13:11:10 Oh, haha 2024-07-07 13:11:26 It actually had 'loongarch64' and not '!loongarch64' 2024-07-07 13:13:03 but anyway, i hope the nix update does not break Loongarch compatibility 2024-07-07 13:17:20 Another MR to look at is !68785, where changes have been requested 2024-07-07 14:29:26 412 aports left for community/ 2024-07-07 15:50:29 cely: thanks, hope you're having a good weekend ^^ 2024-07-07 16:07:28 You're welcome 2024-07-07 16:16:25 401 aports left for community/ 2024-07-07 16:18:12 Hopefully tomorrow 2 problems can be solved: (1) the KDE mirror chosen returns 403, (2) it seems main/ isn't uploaded so each retry also attemps to re-upload new aports in main/ 2024-07-07 16:18:13 attempts* 2024-07-07 16:18:25 and with that the number of aports left can go down much faster 2024-07-07 16:19:28 Over the weekend, i think my constant retrying has managed to bring the number down of aports left by about 110 2024-07-07 16:20:12 and finally there's a (3) i think maybe `apk verify` (if this is the right command) needs to be ran over /home/buildozer/packages 2024-07-07 16:20:45 wasn't it 400 something earlier in the week? that's considerable progress ^^ 2024-07-07 16:20:49 as i don't think dbus is the only package affected (this has been fixed) 2024-07-07 16:21:00 s/this/dbus/ 2024-07-07 16:21:12 where did the main/ packages get uploaded if not to edge ? 2024-07-07 16:22:38 There's dev.a.o/edge that's supposed to get the .apk's from the builder (but i think it is not working, as i said about half a day ago) 2024-07-07 16:22:55 based on the timestamp of APKINDEX.tar.gz 2024-07-07 16:23:17 and there's dev.a.o/~loongarch/edge that gets the manually uploaded packages 2024-07-07 16:25:09 So, to summarize again: (1) KDE mirror 403, (2) builder apparently doesn't upload to dev.a.o/edge, (3) `apk verify` and probably remove those .apk's that fail 2024-07-07 16:29:53 Ok, i think the number has reached 398, and i'll probably stop my retry script soon 2024-07-07 16:31:24 mio: Very likely the credentials to upload to dev.a.o/edge are different from dev.a.o/~loongarch/edge, and so i think the packages are just not uploaded 2024-07-07 16:35:15 ah okay 2024-07-08 01:08:53 I uploaded main to dev.a.o/~loongarch/edge last Saturday 2024-07-08 01:11:39 znley: Help verify this, thanks https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/68734#note_419076 2024-07-08 01:29:47 cely: I just set DISTFILES_MIRROR to distfiles.a.o/edge 2024-07-08 01:37:06 Ok, let's see if that makes things better 2024-07-08 01:37:35 How about the main/ not being uploaded to dev.a.o/edge issue, are you able to solve that (without waiting for n c o p a)? 2024-07-08 01:39:49 I was looking at where ncopa had set this 2024-07-08 01:40:57 algitbot: retry master 2024-07-08 01:41:16 "uploading packages to main" now takes a few minutes 2024-07-08 01:41:35 I expect that once the dev.a.o/edge issue is solved, that will not take so long 2024-07-08 02:08:34 mqtt-exec.aports-build sets loongarch@dev.alpinelinux.org, and once modified, this may require restarting it 2024-07-08 02:08:36 So it may be better for ncopa to modify it 2024-07-08 02:10:08 Ok 2024-07-08 02:11:45 and finally the 3rd issue, about the BAD signature problem 2024-07-08 02:11:56 Not sure how many aports are affected 2024-07-08 02:13:55 But i know that lua5.4 is affected, based on https://build.alpinelinux.org/buildlogs/build-edge-loongarch64/community/libvirt/libvirt-10.5.0-r0.log 2024-07-08 02:14:24 huajingyun: I found two aports disabled on loongarch64 through !68743. 2024-07-08 02:15:42 This mr can passed if we re-enable `py3-referencing` and `py3-jsonschema-specifications` on loongarch64. 2024-07-08 02:16:05 cely: OK, I'm looking at it 2024-07-08 02:16:09 Would deleting lua*5.4.7-r0.apk in /home/buildozer/packages/main force it to be rebuilt? 2024-07-08 02:16:12 And actually these can re-enable. 2024-07-08 02:17:10 Yes, i took over py3-rpds-py and upgraded it to a git revision with libc 0.2.155 precisely to allow those aports to be re-enabled 2024-07-08 02:20:07 Maybe you can try `apk verify lua*5.4.7-r0.apk` first before deleting them to see what it returns 2024-07-08 02:20:30 (I am not sure what command can be used to find those packages with BAD signatures) 2024-07-08 02:21:45 Probably `apk verify` is not the correct command, as i am not sure if it checks APKINDEX.tar.gz, which is probably where the BAD signature thing comes from 2024-07-08 02:23:40 but so far i have noticed dbus and lua5.4 having BAD signatures, dbus is fixed as pkgrel has been bumped 2024-07-08 02:23:50 I executed 'abuild index' and 'apk fix', but it didn't seem to work 2024-07-08 02:24:07 I believe `apk fix` only works for what you already have installed 2024-07-08 02:25:31 Perhaps you can try deleting lua*5.4.7-r0.apk (lua5.4 + its 4 subpackages), and we'll see if it gets rebuilt? 2024-07-08 02:26:06 From /home/buildozer/packages/main, that is 2024-07-08 02:26:53 Yes, I plan to do that 2024-07-08 02:28:40 have done 2024-07-08 02:28:57 algitbot: retry master 2024-07-08 02:29:09 Yes, it gets rebuilt :) 2024-07-08 02:30:12 Yes,let's continue to look at 2024-07-08 02:31:46 znley: Ok, 2024-07-08 02:32:51 For !68913, i think the `go` commands should go into `prepare()`, but probably it would be better if it's made into a patch instead 2024-07-08 02:40:37 cely: yzewei will update it, thanks 2024-07-08 02:44:13 You're welcome 2024-07-08 13:58:29 Hmm, it seems build-edge-riscv64 completed jujutsu 0.19.0 in 42m 24s, while build-edge-loongarch64 took only 10m 30s 2024-07-08 19:46:23 isn't build-edge-riscv64 still qemu 2024-07-08 20:56:55 No 2024-07-08 20:57:10 We have 2 milkv Pioneer boxes now 2024-07-09 01:52:37 Hello everyone, I want to count how many aports are disabled on loongarch64, is there any good way? 2024-07-09 01:56:55 You can loop over all aport directories and do `abuild check_arch`, those where it fails are those that have $CARCH disabled 2024-07-09 01:57:03 Maybe there's a better way to do this 2024-07-09 02:17:22 This is awesome, thank you! 2024-07-09 02:19:50 You're welcome 2024-07-09 02:22:33 For !68973, maybe "fix build" is a big vague, grepping through `git log`, i see commit messages like "fix missing cstdint when compiling with gcc13" or even "fix build with gcc13" which may be better 2024-07-09 02:33:07 cely: Ok,yzewei will update it 2024-07-09 02:36:01 Thanks :) 2024-07-09 02:42:29 Could you please help take a look at !68602 ? 2024-07-09 02:42:34 It failed on builder yesterday and needs to be merged 2024-07-09 02:58:35 Merged 2024-07-09 02:59:56 Thank you :) 2024-07-09 03:01:11 You're welcome 2024-07-09 08:03:00 Less than 100 aports left in community :) 2024-07-09 08:03:07 for the builder, that is 2024-07-09 08:46:00 znley: i made apkgquery for that 2024-07-09 08:46:33 cely: yes, but some unmerged MRs will continue to block the builder 2024-07-09 08:46:44 znley: https://gitlab.alpinelinux.org/kdaudt/apkgquery/ 2024-07-09 08:49:49 That is great, I was recently counting how many aports we builded or disabled on loongarch64. This will be helpful. 2024-07-09 08:50:40 There may be a bug in the latest version with output, in that case, use an earlier version 2024-07-09 08:50:42 Great! 2024-07-09 08:51:32 ikke: Is there any recent progress on CI? 2024-07-09 08:52:43 huajingyun: ikke is away for a few weeks 2024-07-09 08:54:29 Thanks for reminding. 2024-07-09 08:55:26 OK, thanks! 2024-07-09 08:55:34 clandmeter: so will you be free to continue setting up CI soon? 2024-07-09 08:55:41 I think a more pressing issue that needs to be looked into is the builder not uploading to dev.a.o/edge 2024-07-09 08:56:47 i am not uptodate about the status 2024-07-09 08:57:02 ci will run on the current servers? 2024-07-09 08:57:21 im not on par on the current loongarch infra 2024-07-09 08:58:01 Yes, I pinged ncopa yesterday and have not received a response yet. 2024-07-09 09:02:08 clandmeter: there are currently two servers that are idle. According to what ncopa mentioned before, I think CI and dev machines should be set up. 2024-07-09 09:03:26 we have already started testing these machines shipped to the EU 2024-07-09 09:10:59 Im back next week 2024-07-09 09:11:40 Or rather, coming Sunday 2024-07-09 09:15:35 ikke: Ok:) 2024-07-09 09:18:51 heh he can not let go of alpine even if away ;-) 2024-07-09 09:26:34 :-D 2024-07-09 09:33:23 Hmm, rakudo-star is being built by the Loongarch builder now, this should be interesting.. 2024-07-09 09:34:18 Oh and now fortify-headers is in 2024-07-09 09:35:02 I wonder if we should rerun CI for MRs potentially affected by fortify-headers now 2024-07-09 09:40:55 Does this have a big impact? 2024-07-09 09:41:22 The last version did, and had to be reverted 2024-07-09 09:41:52 but the bugs we found from the last version should hopefully be fixed in this one 2024-07-09 09:55:40 That should be necessary 2024-07-09 10:00:40 rakudo-star built successfully on Loongarch :) 2024-07-09 10:14:21 I guess when the dev.a.o/edge uploading issue is solved, we'll finally see "edge/main/loongarch64: uploaded" in #alpine-commits 2024-07-09 10:14:45 I've been wondering why that message doesn't appear 2024-07-09 10:20:55 77 aports left to build for community 2024-07-09 10:21:15 Hopefully soon it will be less than 50 2024-07-09 13:02:25 cely: ncopa will take some time to help, let's wait for a while 2024-07-09 13:03:48 With the dev.a.o/edge upload issue? 2024-07-09 13:05:26 Yes 2024-07-09 13:05:49 Ok 2024-07-09 13:14:57 whats up with the upload issue? 2024-07-09 13:15:00 missing key? 2024-07-09 13:16:22 I'm not sure, maybe? 2024-07-09 13:16:36 Nothing gets uploaded 2024-07-09 13:17:01 it does not get uploaded or it fails? 2024-07-09 13:19:20 That i don't know the answer to :) 2024-07-09 13:20:24 and i think Jingyun has left the office now, so probably it'll just have to wait for ncopa 2024-07-09 13:20:43 What i know is the upload location was switched from dev.a.o/~loongarch/edge to dev.a.o/edge 2024-07-09 13:21:06 ok, and it uploaded previously i guess 2024-07-09 13:21:27 I think when it was at its old location, uploading worked, which is probably one of the reasons why the location was changed (Jingyun is also manually uploading to dev.a.o/~loongarch/edge) 2024-07-09 13:21:52 I can take a look, but i need to know which host it is :) 2024-07-09 13:22:45 Hehe, is there no clue from which host contacts the MQTT server? 2024-07-09 13:23:16 im very clueless :) 2024-07-09 13:24:33 and it looks like we didnt record it yet 2024-07-09 13:24:40 From what i remember, access to the servers is through different ports not IP addresses, so probably it'll have to wait for ncopa anyway 2024-07-09 13:25:29 Ah, Jingyun mentioned once that the builder is on "server3" 2024-07-09 13:25:43 "builder3"* 2024-07-09 13:27:16 found it 2024-07-09 13:43:19 hi 2024-07-09 13:43:48 need to go via ssh jump host 2024-07-09 13:45:53 i think its a permission issue on dev.a.o 2024-07-09 13:45:57 im looking at it now 2024-07-09 13:46:34 im also looking 2024-07-09 13:46:44 it looad like the upload host is still dev..ao 2024-07-09 13:46:50 looks* 2024-07-09 13:47:52 that should be correct? 2024-07-09 13:50:32 i think its uploading now 2024-07-09 13:50:43 i fixed it by fixing ownership on dev.a.o 2024-07-09 13:51:42 yup, it is uploading 2024-07-09 14:06:09 The "uploading packages to main" step now takes around 20 seconds :), when it was failing previously, it took around 3 minutes 2024-07-09 14:10:49 oh i read it incorrectly, thought it was switched from dev to master. 2024-07-09 15:30:03 35 aports left to build for community :) 2024-07-10 01:05:48 That's great! It seems that this problem has been solved 2024-07-10 01:05:58 Thanks! 2024-07-10 01:14:36 Yes, it's been solved 2024-07-10 01:22:28 gsa and containerd blocked the builder, since !67125 and !68984 have not been merged yet 2024-07-10 01:24:19 For those, you may have to ping their maintainers on IRC (tomalok and fcolista) 2024-07-10 01:28:29 OK 2024-07-10 05:45:47 I'm trying to determine what the 9 aports left to build in community/ are 2024-07-10 05:46:29 From #alpine-commits, i see: containerd, vaultwarden, ossec-hids-agent, ossec-hids-server 2024-07-10 05:48:28 To that, i can add the dependencies of containerd: nerdctl, buildkit, docker 2024-07-10 05:48:53 That makes 7, so 2 more 2024-07-10 05:51:04 Probably another one is docker-cli-compose, so 1 more 2024-07-10 08:45:02 There are currently 7 MRs in the community that affect the builder: !68548, !67125, !66233, !67681, !66472, !66414, !66240 2024-07-10 08:45:34 Five of these MRs (66233, 67681, 66472, 66414, 66240) were assigned to @jirutka, and these MRs were created a month ago, but have not received any response 2024-07-10 08:45:40 ncopa: can you help ping jirutka? 2024-07-10 09:29:15 good morning/afternoon/evening! 2024-07-10 09:29:38 I'll have a look at them 2024-07-10 09:30:21 the relationship with jirutka has been challenging in the past. I think he nowadays don't care about things he does not use himself 2024-07-10 09:36:48 OK, thanks! 2024-07-10 09:36:57 Pinged maintainers of other MRs., once those MRs are merged, builders (community) should be able to build quickly. 2024-07-10 09:38:33 However, i merged 2 "move to community" MRs an hour ago: flux and oras-cli 2024-07-10 09:38:46 Well, 3, but the 3rd is only enabled for x86_64 and aarch64 2024-07-10 09:39:07 So, maybe you can have a look and see if anything is needed to make flux and oras-cli build successfully 2024-07-10 09:41:48 cely: Ok, znley will take a look 2024-07-10 09:48:23 flux passed on loongarch64. 2024-07-10 09:49:03 oras-cli pass build pass but check failed. 2024-07-10 09:49:27 error message is '--- FAIL: TestRemote_authClient_resolve (6.35s) 2024-07-10 09:49:27 remote_test.go:220: unexpected error when sending request: Get "https://test.unit.oras:34517": EOF' 2024-07-10 09:50:36 Hmm, is that even a valid domain 2024-07-10 09:54:34 Needs to retry master, the builder log shows a timeout error 2024-07-10 09:56:31 algitbot: retry master 2024-07-10 09:56:50 Another problem, how do I know which aports the builder has built? I would like to get a aport list. 2024-07-10 10:09:41 I think the only way is to subscribe to mqtt 2024-07-10 10:16:31 Ok, I will try it. 2024-07-10 13:42:10 I think of all the MRs mentioned above, we're down to just containerd and suitesparse 2024-07-10 14:06:10 @nmeum has asked for the test failure message of !68916 2024-07-10 15:14:28 containerd merged \o/ 2024-07-11 01:06:23 I just retry master 2024-07-11 01:29:29 oras-cli passed on loongarch64 after I unset http_proxy. 2024-07-11 01:36:36 Ok 2024-07-11 01:38:38 I wonder if you can just set GOMODCACHE and use `go mod download` (on the computer you are testing all this on) to workaround the issues with downloading Go modules 2024-07-11 01:39:01 I mean, it seems to work fine there, but the builder seems to have download issues 2024-07-11 01:44:53 Yes, the network on builder is not stable now, I am coordinating this issue 2024-07-11 01:46:16 Ok 2024-07-11 01:47:17 I remember seeing this Go module download issue last week, but it seems to have cleared up over the weekend 2024-07-11 01:51:05 Good news is that J0WI merged !67192, not so good news (but not that bad) is that a few hours before that lots of neovim-related aports (including py3-pynvim) were disabled 2024-07-11 01:51:57 and i think for neovim the fix got in, but it's still disabled in arch= :) 2024-07-11 01:52:42 Anyway, that gives you all the opportunity to look into this, see which neovim aports work, and enable them all in one go 2024-07-11 01:54:33 Oh, this is the MR that we forgot to close yesterday. Now that it has been merged, let's take a look. 2024-07-11 01:54:41 Hehe 2024-07-11 01:56:38 I guess after closing so many MRs, when J0WI came on gitlab.a.o, and looked for Loongarch MRs, the neovim one came up, and so it got merged 2024-07-11 01:58:53 Nice, it seems py3-oscrypto passed on the builder about half an hour ago 2024-07-11 01:59:23 So, i think out of the 7 MRs you mentioned yesterday, only !66472 remains 2024-07-11 01:59:34 and changes have been requested on that 2024-07-11 02:02:26 Yeah, and then there's vaultwarden, which I plan to disable on loongarch64 for now 2024-07-11 02:02:32 Also, vaultwarden has been disabled 2024-07-11 02:02:32 Haha 2024-07-11 02:03:49 but vaultwarden is Rust, i see you all have fixed it before by updating the libc crate, and now something else broke (typical Rust, if it doesn't break on this version, a future version will break) 2024-07-11 02:06:36 Yes, as you reminded me, I have asked someone to look at mysqlclient-sys upstream 2024-07-11 02:08:15 That's good :) 2024-07-11 02:11:16 Thanks! 2024-07-11 02:13:31 You're welcome 2024-07-11 02:13:56 Hopefully, we can see the builder proceeding to testing/ today 2024-07-11 02:16:18 containerd has built successfully :) 2024-07-11 02:21:54 and now docker has built too 2024-07-11 02:22:18 Good:) 2024-07-11 02:36:04 4 more aports in community :) 2024-07-11 02:36:26 What a coincidence that it's now building flux, after miniflux 2024-07-11 02:40:54 Was flux built first? 2024-07-11 02:40:56 I didn't notice it 2024-07-11 02:42:18 They have nothing to do with each other 2024-07-11 02:42:50 Miniflux is an RSS reader, and Flux is some Kubernetes thing 2024-07-11 02:43:20 Now the second last aport is building, docker-cli-compose 2024-07-11 02:43:52 Ok 2024-07-11 02:44:19 and now the last 2024-07-11 02:44:24 py3-django-rest-framework-guardian 2024-07-11 02:44:25 Now build the last 2024-07-11 02:44:38 Now uploading \o/ 2024-07-11 02:44:39 Finally 2024-07-11 02:45:02 Nice! 2024-07-11 02:49:40 I wonder how many aports there will be in testing/ 2024-07-11 02:52:53 cely: currently about 2619 aports 2024-07-11 02:53:05 No, i mean, how many need to be built 2024-07-11 02:53:36 Which means, how many are newer/have been upgraded, compared to what's now in dev.a.o/edge/testing 2024-07-11 02:55:05 Oh, let's wait and see 2024-07-11 02:57:04 Hmm, i think maybe it'll be 200 or more 2024-07-11 02:57:08 due to the Go rebuild 2024-07-11 03:00:05 Maybe more than 200 2024-07-11 03:00:10 The first upload always takes a while 2024-07-11 03:01:10 Hopefully not too long 2024-07-11 04:22:13 It seems the builder reached testing/ 2024-07-11 04:22:27 but hit a failing aport (rnote), so now it's back working on community/ 2024-07-11 04:23:13 Ah, rnote uses libc 0.5.153 2024-07-11 04:23:20 0.2.153* 2024-07-11 04:24:01 Hopefully nothing i merged to community/ just now causes ... 2024-07-11 04:24:02 Oops 2024-07-11 04:44:10 Maybe i should stop merging MRs to community/ :P 2024-07-11 04:45:14 Other than my own, as i would be happy to do whatever it takes, whether that be disable aport, disable tests, patch something, in order to avoid blocking the builder at community/ 2024-07-11 05:01:48 394 aports in testing/ 2024-07-11 05:02:13 So, it may have been 400 (before it errored out on rnote, and got retried) 2024-07-11 05:52:03 It seems testing/gitoxide fails to build the sha1-asm crate 2024-07-11 06:06:52 394 aports is more than I thought 2024-07-11 06:10:27 I think it includes those that you all have not fixed 2024-07-11 06:11:55 Like the most recent failure, mat2, that's in my Python 3.12 rebuild issue 2024-07-11 06:13:19 Hehe, it seems i did the last testing/mat2 upgrade, and i don't remember that 2024-07-11 06:13:44 and now the builder is building mat2 again 2024-07-11 06:20:18 Well, I see you upgraded mat2 11 months ago:-D 2024-07-11 06:20:31 Long long ago 2024-07-11 06:20:41 Anyway, now it's 366 aports left 2024-07-11 06:26:21 Yes, that's good 2024-07-11 06:26:34 I'm verifying which aports related to neovim can be enabled 2024-07-11 06:28:28 Ok 2024-07-11 06:32:57 Pushed a fix for testing/mat2, hopefully it fixes the build on Loongarch too 2024-07-11 06:44:21 testing/ppl may need update_config_sub 2024-07-11 06:51:50 https://github.com/ericwq/aprilsh failed test: "frontend/signal_linux_test.go:20:45: undefined: syscall.SIGUNUSED" 2024-07-11 06:52:59 Hmm, now one of my aports testing/perl-sys-syscall 2024-07-11 06:55:34 Let me see. 2024-07-11 07:02:21 I found this patch: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1060397;filename=0001-add-loongarch64-and-riscv64-support.patch;msg=10 2024-07-11 07:08:14 I just created !69118 2024-07-11 07:08:30 Ok 2024-07-11 07:14:56 cely: I verified this patch on loongarch64, and the perl-sys-syscall passed 2024-07-11 07:16:01 Will you add this patch to perl-sys-syscall? 2024-07-11 07:20:55 Yes 2024-07-11 07:22:44 Thanks 2024-07-11 07:24:14 You're welcome, it's now merged 2024-07-11 07:44:54 Ok, i'll be going AFK, bye 2024-07-11 07:46:43 Thank you, bye 2024-07-11 07:59:36 I create !69122 for ppl. 2024-07-11 13:59:10 I've started disabling some aports due to the libc crate 2024-07-11 13:59:46 I'll leave gitoxide for you all to have a look (sha1-asm crate fails to build) 2024-07-11 14:08:21 From 394 to 252 aports in testing/, i think that's pretty good for a day 2024-07-11 14:19:35 I've also disabled py3-zimscraperlib 2024-07-11 14:19:59 On loongarch64 only, that is, as it takes 27 minutes to run tests 2024-07-11 14:20:05 and then it fails 2024-07-11 14:20:41 I think its upgrade MR is staled for the moment, so no point spending 27 minutes just to find out that tests fail 2024-07-11 14:45:27 Ok, the number is now 238 2024-07-11 14:45:33 237 now 2024-07-11 14:45:38 but i think the next one will fail 2024-07-11 15:15:46 Hmmm, wmctrl and xa source tarball seem to be no longer available 2024-07-11 15:19:32 230 aports left, i think that's good enough for now, may be going AFK soon 2024-07-11 15:23:39 Here's something for you all to look into: gtkhash fails with some OpenSSL warnings 2024-07-11 15:43:03 Ok, 220 aports now, a good number 2024-07-11 15:43:12 gtkhash is building again, and will fail 2024-07-11 15:43:23 Then the builder will be working on the kernel upgrade 2024-07-11 16:09:05 ecasound may need update_config_guess/sub 2024-07-12 01:18:31 154 aports left now 2024-07-12 01:18:33 I'll take a look at ecasound 2024-07-12 01:20:37 https://gitlab.alpinelinux.org/alpine/aports/-/compare/1582a905...22d3f38c 2024-07-12 01:21:00 Does that address what you all were trying to fix with !68785? 2024-07-12 01:22:41 Also, i believe !68793 (netsed tests) has been fixed, please have a look and close if it is 2024-07-12 01:23:55 Ok 2024-07-12 02:12:22 cely: testing/ocfs2-tools can pass on loongarch64 with https://gitlab.alpinelinux.org/alpine/aports/-/compare/1582a905...22d3f38c 2024-07-12 02:12:36 so, I will close !68785. 2024-07-12 02:15:59 Thanks 2024-07-12 02:59:21 keydb may also need update_config_* 2024-07-12 03:03:06 Ok,let's see 2024-07-12 03:11:43 liblinbox also 2024-07-12 03:19:20 cely: !69142 2024-07-12 03:31:29 I think there are quite a number of Go failures 2024-07-12 03:31:51 as this involved a Go rebuild 2024-07-12 04:24:49 92 aports left 2024-07-12 04:46:23 85 aports left 2024-07-12 05:44:04 66 aports left 2024-07-12 05:44:31 However, the builder keeps going back to the failing aports now 2024-07-12 06:28:37 55 aports left 2024-07-12 07:01:17 Almost 20 years 2024-07-12 07:01:17 hping3 now fails, i think because it doesn't know about the endianness of Loongarch 2024-07-12 07:01:17 After all, pkgver is 20051105 2024-07-12 07:01:46 So, if anyone can fix it, then open an MR for that, or else open an MR to disable it 2024-07-12 07:05:02 There are some other similar aports that have not been maintained upstream for many years. Do we still need to keep them? 2024-07-12 07:13:09 I create !69144 for hping3. 2024-07-12 07:14:53 Thanks, merged 2024-07-12 10:39:19 30 aports left :) 2024-07-12 11:51:37 Maybe when you all get back next week, you can see if !69150 allows the aport to be enabled on Loongarch, it seems this upgrade contains libc 0.2.155 2024-07-12 12:49:43 Ok, the number of aports left to build in testing/ should be 20 now after the qpdfview fix goes in 2024-07-12 12:50:21 What's left is probably mostly Go x/sys needing an update 2024-07-12 12:51:25 and there's testing/gitoxide failing to build the sha1-asm crate, maybe you all can look into that when you get back from the weekend 2024-07-12 12:53:27 Assuming no other big rebuild takes place, i think maybe we can see testing/ get uploaded next week, perhaps after a bulk update of x/sys is done 2024-07-12 13:25:09 build.a.o still shows 21, but it'll be 20 after it gets to qpdfview again 2024-07-12 13:25:10 I think i have a list of the 20 aports, though i haven't double checked it: 2024-07-12 13:26:39 aprilsh, bomctl, castero, dstask, ettercap, gitoxide, haproxy-dataplaneapi, libqb, libretro-beetle-saturn, mailsec-check 2024-07-12 13:28:04 php81-pecl-xmlrpc, pdm, py3-glob2, py3-truststore, rizin, rizin-cutter, snowflake, ssh-cert-authority, usbguard, usbguard-notifier 2024-07-12 13:40:35 Out of that, libqb and ssh-cert-authority have empty Maintainer lines 2024-07-12 13:41:03 and libqb is a dependency of usbguard, which in turn is a dependency of usbguard-notifier 2024-07-12 13:41:15 So, probably you all can concentrate on libqb and ssh-cert-authority 2024-07-12 13:42:23 ssh-cert-authority already has a `go mod edit -replace` line in build() for x/sys, so probably all that's needed is deciding if we want to turn that into a patch, and getting the right version that has Loongarch support 2024-07-12 19:39:49 cely: if you see a loongarch64MR assigned to me, you can just merge it right away 2024-07-12 19:40:08 like a ntpd-rs libc upgrade 2024-07-12 19:44:32 fossdd: it has already been merged :) 2024-07-12 19:48:50 yes but if a loongarch creature sends another MR in with a libc upgrade 2024-07-12 19:50:08 huajingyun: depends a bit on the project. 2024-07-12 19:50:20 fossdd: nod 2024-07-13 02:00:26 Sure, thanks 2024-07-13 02:01:19 However, the libc crate of the latest ntpd-rs is already at 0.2.155, so if an MR is opened for that, it'll be just to remove !loongarch64 from arch= 2024-07-13 02:01:48 Well, if no other crate has Loongarch compatibility issues, that is 2024-07-13 04:02:14 yzw: Hi Zewei, i hope you don't mind that i have fixed testing/ettercap without using your MR !68541 2024-07-13 04:05:32 My commit also fixes implicit declaration warnings, which i can still see in the CI log of your MR 2024-07-13 04:07:01 As for things that you can improve, we usually want to stay as close to upstream as possible 2024-07-13 04:08:55 I see that your MR also changes sys/poll.h to poll.h and CURLOPT_PROTOCOLS to CURLOPT_PROTOCOLS_STR, which may silence some warnings, but as far as i see, these changes are not in upstream master, and the warnings do not cause the build to fail 2024-07-13 05:54:51 Ok, i've worked on 7 aports today out of the 20 i listed yesterday 2024-07-13 05:56:19 My latest commit should hopefully also allow rizin-cutter to be build, making it 8, and i think @andypost also committed a fix for php81-pecl-xmlrpc, making it 9 2024-07-13 05:56:59 Which means the aports to be built should be below 12 now 2024-07-13 05:57:17 Assuming nothing newly committed to testing/ fails 2024-07-13 05:58:40 Now looking through the Loongarch MRs, i think 3 of them are now relevant to unblock testing/: 2024-07-13 05:59:05 !67841, !67122 assigned to @mpolanski 2024-07-13 05:59:19 Argh 2024-07-13 05:59:29 !67841, !67112 assigned to @mpolanski* 2024-07-13 06:00:06 and !68716 assigned to ptrc 2024-07-13 06:01:00 The last one may be builder specific, and logs are available at build.a.o 2024-07-13 06:05:54 If those can be merged, then that will further bring teh count down to 8 (assuming pdm doesn't encounter any other failure after its dependency py3-truststore passes) 2024-07-13 06:05:59 s/teh/teh/ 2024-07-13 06:06:01 s/teh/the/ 2024-07-13 06:06:02 lol 2024-07-13 06:06:29 s/to 8/to below 8/ 2024-07-13 06:08:41 So, what's left out of the 20 from yesterday would be: bomctl, haproxy-dataplaneapi, py3-glob2, ssh-cert-authority, and libqb and its dependencies usbguard and usbguard-notifier 2024-07-13 06:23:34 Ok, seems like a KDE upgrade was merged 2024-07-13 06:23:38 but this will be a bit difficult 2024-07-13 06:23:53 as KDE was the one having 403 issues with the mirror 2024-07-13 06:24:22 so, it'll probably have to wait until all those KDE source archives are available on distfiles.a.o 2024-07-13 06:50:18 cely: I guess I can upload them there manually 2024-07-13 06:51:38 Yeah, that would be good 2024-07-13 06:52:34 Thanks 2024-07-13 06:53:26 done 2024-07-13 06:53:35 (If I didn't mess up :P) 2024-07-13 06:54:12 Since you're here, what do we do about the @mpolanski MRs? 2024-07-13 06:54:30 I mean, specifically the ones for dstask and mailsec-check 2024-07-13 06:54:54 Good question. We could send an e-mail asking about it 2024-07-13 06:57:49 In the meantime maybe disable those aports for Loongarch? 2024-07-13 06:58:25 Though now looking at !67841, maybe it'll need some changes 2024-07-13 07:01:06 Anyway, i guess disabling is what happened to those aports in community/ with MRs that didn't get maintainer feedback 2024-07-13 07:01:31 yeah, if there are no major / large amounts of dependencies, that's reasonable 2024-07-13 07:01:38 that's what we did for rv64 too 2024-07-13 07:11:02 Well, i just had an idea, perhaps DISTFILES_MIRROR could point to a working KDE mirror for the duration of the KDE upgrade 2024-07-13 07:11:39 but probably by the time Jingyun gets back to the office on Monday, all the files would be on distfiles.a.o by then 2024-07-13 07:14:09 Oh, reminds me, I still need to setup the sync and cleanup cronjobs on the new x86* builders 2024-07-13 07:14:20 for distfiles 2024-07-13 07:36:26 Since x86* has finished the KDE upgrade, maybe you could sync distfiles now, so the Loongarch builder can work on KDE 2024-07-13 07:37:37 yes, was working on that 2024-07-13 07:37:47 Ok :) 2024-07-13 07:37:48 That was my idea, trigger the sync 2024-07-13 07:37:50 Thanks again 2024-07-13 07:39:26 Ok, should be done now 2024-07-13 07:41:05 Ok, hopefully there are no build failure surprises in the new KDE 2024-07-13 07:55:44 Seems like it's chugging away now 2024-07-13 12:02:53 I think since testing/tang* and testing/clevis* (4 @mpolanski aports) are already disabled, i'll just disable the other 2 (dstack and mailsec-check) that's currently blocking testing/ 2024-07-13 12:41:34 So, i've reduced the aports to build to 4 2024-07-13 12:41:52 Let's see if testing/ can be uploaded today 2024-07-13 13:08:10 Here goes.. 2024-07-13 13:08:21 I did not dare accept !68921 without approval, so it's been disabled 2024-07-13 13:08:26 on Loongarch, that is 2024-07-13 13:10:06 Now uploading 2024-07-13 13:15:03 So, probably the first MR for you all to look into after the weekend is !67841, it'll have to be an "enable on loongarch64" MR now 2024-07-13 13:16:17 and probably see if the patch itself is good enough the the "go mod" commands in build() can be removed, if "go mod vendor" is needed, then it probably needs to be moved to prepare() 2024-07-13 13:25:46 I've rebased !67112 and !68716 2024-07-13 13:35:44 Well, it seems some new contributors have found a way around @mpolanski aports: !69186 2024-07-13 13:36:01 I wonder why it didn't get auto-assigned 2024-07-13 13:43:57 error_description: Token is expired. You can either do re-authorization or token refresh. 🤔 2024-07-13 13:44:06 fun... 2024-07-13 13:44:35 Oh, so the bot's token expired 2024-07-13 13:45:22 yup 2024-07-13 13:45:45 And generating a new token means a new bot user 2024-07-13 13:45:58 Wow 2024-07-13 13:46:29 Is that because you can't login as the bot and generate a token that way? 2024-07-13 13:46:53 No, when you create a project access token, gitlab creates a user in the background 2024-07-13 13:47:03 Ok 2024-07-13 13:47:06 when you revoke that token, that uses gets deleted 2024-07-13 13:47:15 oohh 2024-07-13 13:47:16 user* 2024-07-13 13:47:33 Well, build-edge-loongarch64 finally uploaded testing/ 2024-07-13 13:47:41 but quite a bit had to be disabled 2024-07-13 13:48:34 i guess thats gine for the beginning 2024-07-13 13:48:38 Hopefully i've been thorough enough with documenting why things were disabled, so others can see when they can be re-enabled 2024-07-13 13:48:42 s/gine/fine 2024-07-13 13:48:45 Ah right 2024-07-13 13:49:05 Now that the builder's idle, maybe i should go and see if ntpd-rs can be enabled 2024-07-13 13:54:04 oh, probably not the bot key that expired (which luckily has a long expiry date), but another token 2024-07-13 13:54:39 So many tokens 2024-07-13 13:55:36 This has been done on purpose. The bot has limited access and defers to another service to be able to query users by e-mail 2024-07-13 13:56:13 Ok 2024-07-13 14:00:15 Ok, token is refreshed, let's see if it works now 2024-07-13 16:39:33 mpolanski just merged an MR assiged to him :) 2024-07-13 16:47:13 Yes, i saw that 2024-07-13 16:47:28 It seems @mpolanski and @jirutka both came on at around the same time 2024-07-13 16:50:32 yeah :D 2024-07-13 16:51:22 Patience is a virtue :) 2024-07-13 17:02:11 I was just about to remark about how long grype is taking to build on the Loongarch builder :D 2024-07-13 17:02:25 and now it's done 2024-07-14 03:59:29 I'm currently trying to enable aports (Python aports, for now) by trying them on the builder 2024-07-14 03:59:52 So, sorry if it gets a bit chaotic, as some aports change their reason for disabling 2024-07-14 04:00:25 (they are enabled, and then disabled again) 2024-07-14 04:34:08 I now count 77 py3-* aports disabled on Loongarch, 28 in community/, 49 in testing/ 2024-07-14 04:48:52 Hopefully what i've enabled doesn't cause issues later on, and sort of makes up for what i had to disable to unblock the builder 2024-07-14 05:18:46 395 aports in community/ have !loongarch64, and 476 have that in testing/ 2024-07-14 06:32:35 For aports i maintain (besides the OCaml aports, for which i think upstream has pretty much rejected Loongarch support), i have 12 with !loongarch64, 6 in community/ and 6 in testing/ :) 2024-07-14 06:33:40 Maybe it'll be back to 7 in community/ now after halloy failed :/ 2024-07-14 06:34:22 I thought i had considered the linux-raw-sys crate, version 0.1.4 fails, but 0.4.14 doesn't 2024-07-14 06:34:43 I check halloy's Cargo.lock, and saw 2 versions of linux-raw-sys, 0.4.14 and 0.6.4 2024-07-14 06:35:05 I didn't expect 0.6.4 to be incompatible with Loongarch again.. 2024-07-14 06:47:57 Hmm, there's actually another error in rustix 2024-07-14 07:22:40 huajingyun: As the builder is now unblocked for all 3 repositories, you can probably ignore all the messages from yesterday, when i was still planning in case it was still blocked when you came back after the weekend 2024-07-14 07:35:23 Anyway, i've thought of 3 things that maybe you all can work on when you get back tomorrow 2024-07-14 07:37:27 (1) testing/haproxy-dataplaneapi has an incompatible github.com/shirou/gopsutil 2024-07-14 07:37:57 Maybe you can see if you can open an MR to enable that, not sure if its maintainer will accept it, but at least it's there 2024-07-14 07:38:39 (2) Go sqlite3 modules, i guess there are actually 2 more widely used ones: 2024-07-14 07:39:25 (a) github.com/mattn/go-sqlite3 used in community/gomuks that i maintain 2024-07-14 07:39:32 https://github.com/shirou/gopsutil/pull/1228 2024-07-14 07:39:45 (b) modernc.org/sqlite used in testing/bomctl 2024-07-14 07:39:49 Oh ok, thanks ikke 2024-07-14 07:40:06 Doesn't seem complete, though 2024-07-14 07:40:49 I think i would like to see how to get community/gomuks enabled on Loongarch, so i welcome an MR for that 2024-07-14 07:41:30 and lastly (3) libqb tests failed, and i disabled the whole aport, which meant usbguard and usbguard-notifier that depends on it also had to be disabled 2024-07-14 07:41:45 Maybe you all can see why libqb tests fail, so we can try to re-enable those 3 aports 2024-07-14 07:43:44 Hmm, testing/haproxy-dataplaneapi uses gopsutil v3.21.11+incompatible 2024-07-14 07:43:59 I wonder why "+incompatible" and if that'll make it harder to bump to the version with Loongarch support 2024-07-14 07:46:34 v3 doesn't use go modules yet 2024-07-14 07:46:49 v4 does 2024-07-14 07:50:00 more precise, v3.21.12 included them 2024-07-14 07:50:00 Ok 2024-07-14 07:57:12 v3.23.2 seems to be the oldest version that has that PR 2024-07-14 07:58:20 Ok 2024-07-14 07:58:35 Anyway, just wondering what you mean by "go modules" when you said v3 didn't use them? 2024-07-14 07:59:38 https://github.com/shirou/gopsutil/tree/v3.21.11 there is no go.{mod,sum} in the toplevel, though I did notice later that they are present in the v3 directory 2024-07-14 07:59:56 But if dataplaneio does not use the /v3 version, then it would use the top-level 2024-07-14 08:00:21 v3.21.12 removed the v3 directory and moved everything to the top-level 2024-07-14 08:00:22 Ah ok, thanks, i almost guessed that you meant the go.{mod,sum} files 2024-07-14 08:00:26 Alright 2024-07-14 08:00:44 That probably explains the "+incompatible" 2024-07-14 08:01:56 dataplaneapi* 2024-07-14 08:04:20 github.com/shirou/gopsutil v3.21.11+incompatible => indeed no /v3 2024-07-15 00:13:28 I think community/plantuml has been building for about an hour now 2024-07-15 00:16:55 It seems this is the first time that is being built with gradle-8.8.patch (that was added without bumping pkgrel) 2024-07-15 00:20:45 Anyway, just wondering if you all have a log of how long plantuml took to build the last time (when it ran without gradle-8.8.patch) 2024-07-15 01:03:19 Seems it built successfully in the end 2024-07-15 01:24:44 Now testing/openbao fails 2024-07-15 01:25:33 Let me fix it. 2024-07-15 01:26:12 Ok 2024-07-15 01:31:47 I've disabled it 2024-07-15 01:32:04 so maybe your MR can say "enable on loongarch64" instead 2024-07-15 01:32:34 It's the Go module that was discussed just yesterday (gopsutil), should be just a few lines above in the history 2024-07-15 01:33:36 So, if you are working on it, you might as well send patches for both aports affected: openbao, and haproxy-dataplaneapi 2024-07-15 01:35:44 From what i gathered from the discussion yesterday, it seems Loongarch support was added into a version of gopsutil that already merged the /v3 directory into the toplevel? 2024-07-15 01:36:38 and it seems haproxy-dataplaneapi doesn't use /v3, but from what i see, openbao does 2024-07-15 01:37:16 I think the better way is disable openbao and I create PR to openbao upstream. 2024-07-15 01:37:30 Sure, that sounds good 2024-07-15 01:37:33 Already disabled :) 2024-07-15 01:39:57 Thanks! 2024-07-15 01:43:27 You're welcome, i also want to keep the builder from being blocked again :) 2024-07-15 02:34:41 I create PR to openbao upstream, but there is no good way for haproxy-dataplaneapi, it does not use /v3. 2024-07-15 02:44:25 Ok 2024-07-15 02:45:21 Let's wait and see if haproxy-dataplaneapi's maintainer asks for it to be enabled on all architectures 2024-07-15 04:06:21 I'm preparing for the next Rust release again: !69243 2024-07-15 04:06:43 I'd appreciate it if you all can verify that it works on Loongarch :) 2024-07-15 04:07:33 I've greatly simplified the Loongarch patches, now there's just 1 patch left, the same patch is applied to whatever incompatible libc crate versions is included 2024-07-15 06:45:16 cely: Ok, I will verify !69243 2024-07-15 06:45:33 Thanks 2024-07-15 06:46:41 You're welcome. 2024-07-15 06:46:48 It looks like rust upstream should be released in 10 days 2024-07-15 06:47:04 Yes 2024-07-15 06:47:21 and actually, usually on Monday, the pre-release will be out 2024-07-15 06:47:36 (next Monday) 2024-07-15 06:47:49 and i think i've only seen the pre-release differ from the release once 2024-07-15 06:48:24 Any reason why you mentioned that it'll be released in 10 days? :) 2024-07-15 06:50:17 I've seen this: https://github.com/rust-lang/rust/pull/126298 2024-07-15 06:51:03 but that seems to be in 1.81.0's milestone 2024-07-15 07:15:23 Hehe, I asked our rust developers last month, the next release should be on the 25th of this month 2024-07-15 07:15:26 Anyway, it's very good for loongarch64, we will gradually get rid of these patches 2024-07-15 07:16:28 :) 2024-07-15 07:17:03 I wonder if "Tier 2 with host tools" for 1.81.0 already means no patches are needed 2024-07-15 07:18:29 huajingyun: i just received an email 2024-07-15 07:20:55 clandmeter: about those machines? 2024-07-15 07:21:25 which are send to me i guess :) 2024-07-15 07:21:28 not the others 2024-07-15 07:23:20 It should be sent by customs. I should inform you later today. All machines will be shipped in the next two days. 2024-07-15 07:24:33 I think each machine recipient will receive it individually 2024-07-15 07:27:25 ok thats good to know 2024-07-15 07:27:31 I need to prepare a router for them 2024-07-15 07:28:15 midasi: ill try to fix t hat asap 2024-07-15 08:24:42 clandmeter: Ok 2024-07-15 09:57:14 cely: !69243 works fine on loongarch64 2024-07-15 09:57:19 alpine:~/packages/Celeste/loongarch64$ rustc -vV 2024-07-15 09:57:19 commit-date: 2024-07-12 2024-07-15 09:57:19 binary: rustc 2024-07-15 09:57:19 rustc 1.80.0 (b8b9158f2 2024-07-12) (Alpine Linux 1.80.0-r0) 2024-07-15 09:57:19 commit-hash: b8b9158f2c4e7ea5a09361def282067fa55c782d 2024-07-15 09:57:21 host: loongarch64-alpine-linux-musl 2024-07-15 09:57:21 release: 1.80.0 2024-07-15 09:57:23 LLVM version: 18.1.8 2024-07-15 09:58:00 Very good, thanks :) 2024-07-15 09:59:04 Too bad the 1.80.0 beta doesn't agree well with one arch (s390x, that keeps going out of memory) 2024-07-15 09:59:21 Hopefully, that doesn't hold back every other arch 2024-07-15 10:04:24 You're welcome:) 2024-07-15 14:47:37 Looks like something from KDE (kdiff3) is going to block community/ again until its source archive is available on distfiles.a.o 2024-07-15 14:48:50 I wonder if abuild could support multiple distfiles mirrors 2024-07-15 14:48:51 lol 2024-07-15 14:49:17 Then this problem could be solved by having the 1st mirror as distfiles.a.o, and the 2nd as a working KDE mirror 2024-07-16 01:04:21 I just downloaded the kdiff3 source archive via "abuild fetch" on builder 2024-07-16 01:16:19 Ok 2024-07-16 01:16:23 That's good 2024-07-16 01:24:05 Yes, the upload is complete 2024-07-16 02:13:12 Wow, it seems like the x86_64 CI is down today, so no CI is green 2024-07-16 04:35:13 It should be back 2024-07-16 05:40:21 https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1454847 2024-07-16 05:48:34 Ah, a loongarch CI 2024-07-16 05:53:50 https://gitlab.alpinelinux.org/Celeste/aports/-/jobs/1454876 2024-07-16 05:54:33 It's not working yet 2024-07-16 05:55:26 some BAD SIGNATURES 2024-07-16 05:55:50 And also permission denied 2024-07-16 05:56:13 I'll look at that later, but please don't merge any ci changes 2024-07-16 05:56:21 Ok 2024-07-16 06:04:07 https://gitlab.alpinelinux.org/Celeste/aports/-/jobs/1454906 2024-07-16 06:05:53 Great! CI is online 2024-07-16 06:07:27 Well, the changes have not been merged 2024-07-16 06:07:37 I'm just playing around with it :) 2024-07-16 06:11:16 It looks like CI installs packages using dev.a.o/~loongarch/edge instead of dev.a.o/edge 2024-07-16 06:11:44 hehe 2024-07-16 06:11:47 That's just me 2024-07-16 06:12:10 Because the alpine-keys in dev.a.o/edge doesn't seem to contain the Loongarch key 2024-07-16 06:12:23 Yes 2024-07-16 06:12:39 So, the CI downgrades to that, and causes bad signature errors 2024-07-16 06:12:57 and vivid passes CI :) 2024-07-16 07:46:02 With the help of CI, i've managed to patch another 2 of my aports for Loongarch 2024-07-16 07:47:08 but the funny thing is, i updated etcd.io/bbolt for gomuks, and that makes gomuks depend on libstdc++ 2024-07-16 07:47:12 only on Loongarch 2024-07-16 07:48:18 Other archs don't seem to have that 2024-07-16 08:04:22 I should only have 10 non-OCaml aports left with !loongarch64, 5 in community/, 5 in testing/ :) 2024-07-16 08:09:44 Anyway, if anyone has some time to look at https://dup.pw/alpine/aports/dda063ea4814 , i'd appreciate if you can tell me whether this is what you would do to patch gomuks for Loongarch support 2024-07-16 08:24:10 cely: Ok, I can verify it later. 2024-07-16 08:25:05 If you're talking about gomuks, there's no need to, it's already been built by the builder 2024-07-16 08:25:11 I tested it in CI first :) 2024-07-16 08:26:04 https://gitlab.alpinelinux.org/Celeste/aports/-/jobs/1454990 :) 2024-07-16 08:28:49 OK, thanks! 2024-07-16 08:28:55 if there are other aports that need verification, just let me know 2024-07-16 08:29:08 Ok 2024-07-16 08:29:47 Hopefully the alpine-keys issue can be sorted out so the Loongarch CI can be enabled for everyone 2024-07-16 08:34:38 Maybe something you can look into is testing/libqb failing tests, if libqb can be enabled, then very likely, usbguard and usbguard-notifier that depend on it can be enabled too 2024-07-16 08:35:22 It would also solve the current problem if we created an alpine-keys-loongarch aport for loongarch64, as you suggested before 2024-07-16 08:35:37 Haha, you remember that suggestion 2024-07-16 08:36:11 Anyway, i'll be going AFK now, so bye 2024-07-16 08:38:06 Sure, in addition to merging !61715, this is also a solution 2024-07-16 08:38:22 cely: Ok,bye 2024-07-16 14:29:41 It seems (at least to me) the download speed of the CI isn't really good 2024-07-16 14:30:41 So, for example, Rust, which is a big download takes a long time to install, but once it is, the actual build runs fast enough 2024-07-16 14:49:23 Yes, that's why I'm hesitant to enable ci by default just yet 2024-07-16 14:51:28 Ok 2024-07-16 19:31:09 Ok, something I was not expecting, but apk even removes unmanaged keys from /etc/apk/keys :/ 2024-07-16 19:47:30 hmm, the fakeroot package is different between the builder and what's on dev.a.o/edge 2024-07-16 19:50:07 And so are more packages 2024-07-16 20:02:14 These packages have newer timestamps than the builder, and the builder is setup to not overwrite those 2024-07-17 01:20:15 ikke: the difference in packages is probably because the builder uses dev.a.o/~loongarch/edge-9c13e7 2024-07-17 01:48:48 Are we talking about the difference between /home/buildozer/packages and dev.a.o/edge ? 2024-07-17 02:02:31 No 2024-07-17 02:02:47 It's about CI, but not sure if the builder ikke refers to is the host, because the host uses dev.a.o/~loongarch/edge-9c13e7, so some packages will be different from dev.a.o/~loongarch/edge (version or timestamps) 2024-07-17 03:25:14 Ok 2024-07-17 04:46:40 With the builder I actually mean the edge builder 2024-07-17 04:47:08 I noticed it because some packages still gave BAD SIGNATURE, even with the correct key in place 2024-07-17 04:50:33 Is there a way of detecting those bad signature packages? 2024-07-17 04:50:41 I noticed dbus and lua5.4 2024-07-17 04:51:45 That was a while ago 2024-07-17 04:52:38 Fixed dbus with pkgrel bump (merged an MR for that), and i think lua5.4 was fixed by removing the .apk from /home/buildozer/packages 2024-07-17 04:53:56 So, i think if you're using dev.a.o/~loongarch, probably dbus and lua5.4 will still give bad signatures 2024-07-17 04:54:47 Seems like the new release of gomuks builds fine on Loongarch without any patches 2024-07-17 04:55:04 though it still links to libstdc++, which other archs don't 2024-07-17 04:55:44 cely: I mean, I can just manually run the rsync job without --update and it will overwrite those 2024-07-17 04:55:50 just curious to what happened 2024-07-17 04:56:00 (on the builder they are valid) 2024-07-17 04:56:16 Yes, dbus and lua5.4 should be fixed on the builder 2024-07-17 04:56:26 So, you're saying they were still giving bad signatures on dev.a.o/edge ? 2024-07-17 04:56:56 Probably not dbus 2024-07-17 04:57:01 as that was solved through pkgrel bump 2024-07-17 04:58:26 cely: yes 2024-07-17 04:58:56 So, are there any packages on dev.a.o/edge besides lua5.4 that gives bad signatures? 2024-07-17 04:58:56 rsync says that the timestamp of all packages are different, and some have different sizes 2024-07-17 04:59:07 Wow 2024-07-17 04:59:35 Could it be because dev.a.o/edge was copied from dev.a.o/~loongarch/edge ? 2024-07-17 04:59:43 Maybe that would affect the timestamps 2024-07-17 04:59:46 ERROR: fakeroot-1.35.1-r0: BAD signature 2024-07-17 04:59:54 ERROR: libpsl-0.21.5-r2: BAD signature 2024-07-17 05:00:47 I would expect ncopa to have synced ~loongarch/edge to the builder, which would then upload it to /edge 2024-07-17 05:00:50 So, how would you detect such things without actually installing those packages? I think `apk verify` doesn't detect this? 2024-07-17 05:03:06 According to git log, dbus and lua5.4 were modified on 2024-06-26, and fakeroot and libpsl on 2024-06-27 2024-07-17 05:03:44 So, maybe something happened around then 2024-07-17 05:04:08 Did the builder upload everything to /edge ? 2024-07-17 05:04:40 I think dev.a.o/edge/community and dev.a.o/edge/testing were already populated before the builder even reached those repos 2024-07-17 05:05:29 and the builder actually failed to upload to /edge/main (it was still blocked at community/ then) 2024-07-17 05:05:34 for a few days, i think 2024-07-17 05:05:50 and from i what gathered, it was a permission issue on dev.a.o 2024-07-17 05:06:23 right now what's preventing updates is the newer timestamps 2024-07-17 05:06:29 so I guess that's the issue 2024-07-17 05:06:48 at least, as long as the package name is the same 2024-07-17 05:06:59 The timestamps on dev.a.o/edge are newer than /home/buildozer/packages ? 2024-07-17 05:08:50 june 26th vs juli 1st for fakeroot 2024-07-17 05:11:04 I think it was around 3rd July that the upload location was switched from dev.a.o/~loongarch/edge to dev.a.o/edge 2024-07-17 05:11:38 Yes 2024-07-17 05:11:54 Looking at the log from back then ncopa said he made hardlinks from the old directory to the new one 2024-07-17 05:12:28 So, probably that's what's causing the rsync issue 2024-07-17 05:14:09 I think chronology of the events went something like this, builder was uploading to ~loongarch/edge for a few days, but that conflicted with Jingyun who was also uploading there, so it was moved to /edge (and now looking at the log, hardlinks were used) 2024-07-17 05:14:33 but the permissions on /edge were wrong, so the builder couldn't upload to /edge for a few days 2024-07-17 05:20:26 The Loongarch builder came online on 2024-06-28 2024-07-17 05:21:19 So, i wonder if something didn't get uploaded properly, causing bad signatures on fakeroot and libpsl from one day earlier, and dbus and lua5.4 from the day before that 2024-07-17 05:24:50 To summarize, 2024-06-28 builder comes online, 2024-07-03 upload directory changed to /edge, and 2024-07-09 permissions on /edge are fixed 2024-07-17 05:25:50 So, i think between 2024-06-28 and 2024-07-03 the builder could upload to ~loongarch/edge, but from 2024-07-03 to 2024-07-09 the builder couldn't upload to /edge 2024-07-17 05:28:00 and i think from 2024-06-28 to 2024-07-03 the builder only uploaded once, to main/, after libseccomp was manually uploaded (MR for that is still open now) 2024-07-17 05:28:57 after that upload, alpine-keys was overwritten and installed on the builder, causing /etc/apk/keys to be empty, and nothing could be built 2024-07-17 05:30:40 Which is also unexpected. I would not expect apk to remove files in /etc that it didn't manage 2024-07-17 05:31:29 Was it not managed? 2024-07-17 05:31:37 I think the alpine-keys from before that had the Loongarch key in it 2024-07-17 05:32:30 At least when i was building a docker image, it removed the key 2024-07-17 05:33:16 Maybe the alpine-keys from the Docker image also has the Loongarch key, so that would make it managed 2024-07-17 05:33:56 That's plausibel 2024-07-17 05:34:59 alpine-keys at dev.a.o/~loongarch/edge is at 2.5-r0 (very likely manually uploaded) 2024-07-17 05:35:29 at dev.a.o/edge it is 2.4-r1 2024-07-17 05:36:07 which i think doesn't contain the Loongarch key 2024-07-17 05:36:21 which is probably why i could make CI work by using dev.a.o/~loongarch/edge as mirror 2024-07-17 05:37:43 Not sure how this was solved on the builder (whether the Loongarch key was manually added to /etc/apk/keys, or if alpine-keys is also at 2.5-r0 there) 2024-07-17 05:41:30 good morning! 2024-07-17 05:41:38 what did I break this time? 2024-07-17 05:41:39 Hello 2024-07-17 05:41:45 rsync? 2024-07-17 05:42:02 Timestamps, hardlinks... 2024-07-17 05:42:35 I think rsync doesn't upload some packages to dev.a.o/edge due to timestamps being newer 2024-07-17 05:43:16 and probably that has something to do with hardlinks being used when the upload directory was moved from ~loongarch/edge to /edge ? 2024-07-17 06:11:35 The edge builder should have been successfully uploaded to dev.a.o/edge, the latest time is today(2024-7-17) 2024-07-17 06:11:40 I haven't manually uploaded packages to dev.a.o/~loongarch/edge in the past few days 2024-07-17 06:16:13 Yes, i've noticed 2024-07-17 06:16:33 I think the issue is not latest packages being uploaded to dev.a.o/edge 2024-07-17 06:17:03 but rather some packages from earlier on did not get uploaded 2024-07-17 06:33:32 The loongarch key in the edge builder is manually copied to the /etc/apk/keys directory, so the apk can work properly. At this time, the alpine-keys on the builder is still 2.4-r1 2024-07-17 06:34:17 Ok 2024-07-17 06:34:20 ikke: cely's guess is correct, alpine-keys in minirootfs contains loongarch key, but when you use dev.a.o/edge, alpine-keys will be downgraded to 2.4-r1, so it will report BAD signature error 2024-07-17 06:39:09 Plasma 6.1.3 merged, do i sense the builder getting blocked again due to the KDE mirror.. 2024-07-17 06:50:22 huajingyun: yes, I was aware of that, and trying to manually include the correct key for now 2024-07-17 06:50:31 Which is working now 2024-07-17 06:50:37 :) 2024-07-17 07:02:11 ikke: ok,so will ci be enabled by default for loongarch64? 2024-07-17 07:02:13 and is it still blocked by the rsync problem you just mentioned? 2024-07-17 07:10:14 I will first test it a bit 2024-07-17 07:10:25 And yes, it's atm still blocked 2024-07-17 07:11:34 I think initially we'll make it a manual, optional job. 2024-07-17 07:17:57 OK, thanks 2024-07-17 07:18:13 who has the authority to manually trigger loongarch ci, the creator of the MR, or the maintainers? 2024-07-17 07:18:28 Both 2024-07-17 07:19:15 Not necessarily the package maintainers if they didn't make the MR 2024-07-17 07:22:54 okay, thank you 2024-07-17 07:23:01 Anyway, this is helpful to see if MRs work well on loongarch64 2024-07-17 08:41:01 And FYI, that's only initially. if it turns out to work well enough, we can turn it on by default 2024-07-17 09:07:17 ACTION waits to see the Loongarch CI appear 2024-07-17 10:16:57 I'll proceed to manually sync the packages to fix the signature errors 2024-07-17 10:22:48 synced main now 2024-07-17 10:43:23 :) 2024-07-17 10:46:48 So, how many jobs can the Loongarch CI run at once? 2 like the other archs? 2024-07-17 10:46:49 Not sure if I should sync community while things are still building 2024-07-17 10:47:07 yes, but we have an extra server, so we could bump it to 4 2024-07-17 10:47:50 It's anoying, building build-base (one of the base images for CI), takes about 5 to 10 minutes 2024-07-17 10:49:12 Are things building? 2024-07-17 10:49:25 https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1456103 2024-07-17 10:49:28 Aren't the KDE packages still blocked by the mirror 2024-07-17 10:49:30 Oh 2024-07-17 10:49:33 You mean CI 2024-07-17 10:49:56 I mean, the builder is not finished with community 2024-07-17 10:50:23 The Loongarch builder? 2024-07-17 10:51:19 yes 2024-07-17 10:51:30 so there are still duplicate packages and all 2024-07-17 10:51:35 but not sure if it hurts 2024-07-17 10:51:47 (the builder only cleans up at the end) 2024-07-17 10:52:12 Ah ok 2024-07-17 10:53:22 But at least with main synced, I can build build-base again 2024-07-17 10:53:35 :) 2024-07-17 10:56:15 Perhaps you could sync distfiles so the KDE stuff can go through...but i see that some other archs are blocked on libplasma and kgamma so not sure if those will block Loongarch 2024-07-17 10:57:19 https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1456122 2024-07-17 10:57:22 syncing 2024-07-17 10:58:31 Afk now 2024-07-17 10:58:51 Bye 2024-07-17 13:57:05 So, we have an Alpine Linux Matrix space? (!69360) 2024-07-17 13:57:42 Time for someone to start something on Jabber (XMPP) too 2024-07-17 21:08:06 oh huh, TIL 2024-07-17 21:09:08 wasn't that supposed to be hosted by someone from Alpine though? brixit.nl is MartijnBraam, a pmOS developer 2024-07-17 21:13:50 We're still waiting for that to be delivered 2024-07-18 00:55:14 Well, the pmOS hosted one is now in our Neochat package, so.. 2024-07-18 01:01:48 Anyway, that reminds me, ejabberd has had support for Matrix for 2 releases now, i need to find some time to see what that's all about 2024-07-18 01:36:43 Wow, i just remembered another one of my aports, community/txr, and wondered if it builds on Loongarch 2024-07-18 01:37:13 Then i checked the release notes for it, and find that support was added 2 years ago 2024-07-18 02:45:41 Now i'm trying to bang Loongarch support into community/pijul 2024-07-18 02:45:57 It seems to be just the nix crate that is causing problems 2024-07-18 02:48:37 and libc of course, but that's an easy fix 2024-07-18 03:18:52 If pijul succeeds, i'll have 4 non-OCaml aports in community/ and 3 in testing/ with !loongarch64 :) 2024-07-18 06:07:09 cely: thank you very much 2024-07-18 11:11:49 Has community/ been synced to dev.a.o/edge? 2024-07-18 11:27:58 No 2024-07-18 18:44:02 ncopa: can you do a dmidecode on your loongarch machine 2024-07-18 18:44:31 i uhh, wish to buy my own for experiments 2024-07-18 19:04:04 Ariadne: I can and will, but not until Monday unfortunately. I barely had time to plug it in and boot it to take a picture :) 2024-07-18 19:04:28 no worries, i just want to figure out what the motherboard model is 2024-07-18 19:39:03 Ariadne: https://tpaste.us/NBrl 2024-07-18 21:26:37 I've setup a 2nd ci runner on the 3rd machine so that we can run more jobs in parallel. Network really is a bottleneck for now. Davide said he received the new servers, so hopefully they are solved soon (clandmeter mentioned he's working on the router) 2024-07-19 01:06:26 ikke: Thanks, regarding the network, I am coordinating with the network administrator to see if it can be improved. 2024-07-19 04:11:49 I hope we can get them all online end of next week. Depending also on Davide if they have time 2024-07-19 06:07:36 clandmeter:Thanks! 2024-07-19 06:48:15 ikke: Hi, we want to enable openjdk8 on loongarch64. I have uploaded the locally compiled apk packages to https://dev.alpinelinux.org/~loongarch/edge/community/loongarch64/ 2024-07-19 06:48:19 I want to copy these packages to the builder, how can I do it? 2024-07-19 06:51:39 Here are the modifications: https://gitlab.alpinelinux.org/znley/aports/-/commit/ef44b5319d886467a2874166d2a75f18038f8d5b 2024-07-19 06:51:59 znley will create a MR for openjdk8 later 2024-07-19 06:55:37 huajingyun: apk add -X openjdk8-bootstrap 2024-07-19 06:56:13 On the builder? 2024-07-19 06:57:28 Yes 2024-07-19 06:58:26 Ah okay 2024-07-19 06:58:42 pkgrel bump will not be needed because the builder has not built openjdk8 2024-07-19 06:58:51 but the patch will have to get in 2024-07-19 06:58:57 So the builder can build that 2024-07-19 06:59:10 ikke: Ok，thanks 2024-07-19 07:00:21 A package cannot makedepends on itself (abuild filters it out) 2024-07-19 07:00:40 That's why it depends on the -bootstrap package 2024-07-19 07:03:19 After the package is built, it needs to be removed again 2024-07-19 07:07:33 Ok,now that openjdk8 is installed in the builder 2024-07-19 07:07:58 Alright, i guess next step is the MR for the patch 2024-07-19 07:08:03 znley:You can create a MR 2024-07-19 07:08:12 Merge that, and the builder will start building 2024-07-19 07:10:03 Would fail on CI 2024-07-19 07:10:16 But that's optional anyway 2024-07-19 07:10:24 After it is built on the builder, I will then manually del openjdk8 2024-07-19 07:11:35 The compilation of opejdk8 always takes a while 2024-07-19 07:15:07 I think x86* and aarch64 CIs will complete in under 10 minutes 2024-07-19 07:15:31 So, i will probably get it in when those 3 are green 2024-07-19 07:25:18 Ok, ppc64le is green now as well 2024-07-19 07:25:29 So, let's build it :D 2024-07-19 07:31:31 Thank you! 2024-07-19 07:32:13 You're welcome 2024-07-19 10:04:28 ikke: OpenJDK8 failed to build on the builder,with "make: *** [Makefile:2048: stamps/icedtea.stamp] Terminated" 2024-07-19 10:04:39 Is there a compilation time limit on builder? 2024-07-19 10:05:46 Building openjdk8 locally is no problem, but it does take a long time 2024-07-19 10:16:04 huajingyun: no, there is no limit 2024-07-19 10:18:56 Ok, I just retriggered it 2024-07-19 10:22:59 ikke:but this takes really too long to compile (about 3 hours) and by that time I'm already gone, if it passes, can you help to del openjdk8 on builder? 2024-07-19 10:23:35 huajingyun: yes, will do 2024-07-19 10:25:06 ikke: thanks you! 2024-07-19 10:25:20 Hope this build goes smoothly 2024-07-19 10:39:54 I hope it isn't getting terminated due to going out of memory 2024-07-19 10:40:59 I just checked, the builder should have plenty 2024-07-19 10:41:30 128G mem 2024-07-19 10:42:12 Ok 2024-07-19 12:34:26 Hmm, why did openjdk8 fail again :( 2024-07-19 12:38:32 I wonder if something happened 2024-07-19 12:38:40 !69387 failed too, on the CI 2024-07-19 12:38:59 However, !69388 passed 2024-07-19 15:09:58 I did see some other CI jobs fail (intermittently) with 'terminated' as wellb 2024-07-19 15:10:06 but no clue where that comes from 2024-07-19 15:19:07 Which archs? 2024-07-19 15:19:26 You may be thinking about the Qt/KDE stuff on 32-bit 2024-07-19 15:19:41 but that's on the builders, not the CI 2024-07-19 15:20:03 Maybe for CI, it could be riscv64 that you're thinking about 2024-07-19 15:23:44 loongarch64 2024-07-19 15:23:52 But maybe rich64 2024-07-19 15:27:09 rich by 64? 2024-07-19 15:27:38 :D 2024-07-19 15:27:54 i recieved my loongarch desktop 2024-07-19 15:27:56 Didn't you know dalias has it's own architecture? 2024-07-19 15:27:57 nice little machine 2024-07-19 15:28:01 clandmeter: cool 2024-07-19 15:28:16 ill try it soon and add it to ci 2024-07-19 15:28:45 huajingyun: is there any developer information about these boxes? 2024-07-19 15:28:48 clandmeter: take into account there are no published loongarch64 docker images yet 2024-07-19 15:29:15 where should i pull one from? 2024-07-19 15:29:21 or can i build one locally? 2024-07-19 15:32:27 Apparently there is one here: https://dev.alpinelinux.org/~loongarch/edge/releases/loongarch64/alpine_edge_docker_images.tar 2024-07-19 15:32:47 But you also need to build a couple of other images for CI 2024-07-19 15:33:20 I was thinking about hosting it on registry.a.o, but did't have time to set anything up yet 2024-07-19 16:41:52 apparently docker also refuses to support loongarch64 for their official images... 2024-07-19 16:55:26 fossdd: reference? 2024-07-19 17:24:00 https://github.com/docker-library/official-images/issues/16404 2024-07-19 17:27:39 Ok, so not popular enough (yet) 2024-07-19 17:29:13 i believe so 2024-07-20 02:14:32 It seems openjdk17 is also failing like openjdk8 2024-07-21 09:06:33 which repo shoudl i use? dev.a.o/edge or the other one? 2024-07-21 09:06:50 I think you should use dev.a.o/edge 2024-07-21 09:06:59 The other one hasn't been updated for a while 2024-07-21 09:07:52 Well, it does have community/openjdk8, which together with openjdk17, doesn't want to build on build-edge-loongarch64 for some reason 2024-07-21 09:08:44 The machine I got use the older one 2024-07-21 09:08:52 did you switch it? 2024-07-21 09:09:05 i guess yours is the same 2024-07-21 09:09:31 Switched 2024-07-21 09:09:48 Anyway, CI also uses dev.a.o/edge as far as i know, but with dev.a.o/edge, you have to be careful about upgrading with --available, as alpine-keys in dev.a.o/edge doesn't have the Loongarch key 2024-07-21 09:16:52 the keys in /edge wont work with /edge? 2024-07-21 09:20:28 I think so 2024-07-21 09:20:44 th 2024-07-21 09:20:45 thx 2024-07-21 09:20:59 After all, /edge is built from Git exclusively now, no more manual uploading 2024-07-21 09:21:01 i backed it up 2024-07-21 09:21:08 and moved it back 2024-07-21 09:21:14 :) 2024-07-21 09:21:23 seems apk keys does not provide any key for loongarch 2024-07-21 09:22:48 The MR has not been merged: !61715 2024-07-21 09:25:06 From what i've heard, i think the plan is to generate new keys once the builders are set up in Europe 2024-07-21 09:27:43 we will have a discussion about it 2024-07-21 09:27:59 but i think it makes sense to temporary add this key 2024-07-21 09:28:07 else the repo is kind of... 2024-07-21 09:29:17 I think you should ask ncopa and ikke about it as the MR has been left unmerged for a while now 2024-07-21 09:30:04 and ikke worked around that issue for the CI image by manually adding the key to it 2024-07-21 09:30:14 i already talked about it :) 2024-07-21 09:30:33 but not yet with ikke 2024-07-21 09:41:57 cely: did you know the reason why the onboard hdmi is not functioning? 2024-07-21 09:42:30 I also noticed there are no blobs in the boot process 2024-07-21 09:42:33 which is nice 2024-07-21 09:42:42 or am i missing something 2024-07-21 09:42:49 Sorry, nope, will have to ask Jingyun about that 2024-07-21 09:56:34 ok will do, thx 2024-07-21 10:04:37 ikke: ping 2024-07-21 10:04:43 pong 2024-07-21 10:04:48 ah you are lurking :) 2024-07-21 10:04:59 Well, I just came home as well 2024-07-21 10:05:22 which repo is for ci? 2024-07-21 10:05:45 I created alpine image myself 2024-07-21 10:05:47 /edge 2024-07-21 10:06:02 i mean for the runner 2024-07-21 10:06:05 i guess its not in the repo 2024-07-21 10:06:09 i need to build it myself 2024-07-21 10:06:16 clandmeter: If you want to setup a runner, easiest is to rsync the repos from one of the existing runners 2024-07-21 10:06:34 I made certain changes to make it work (one of which is to inject the key) 2024-07-21 10:06:56 if my base image has the key its ok right? 2024-07-21 10:07:31 There are some small other changes as well, but yes, should be fine 2024-07-21 10:07:37 there are 4 repos you need 2024-07-21 10:07:56 gitlab-runner, gitlab-runner-helper, build-base and alpine-gitlab-ci 2024-07-21 10:08:05 and then the gitlab-runner-alpine-ci project for the actual runner 2024-07-21 10:09:16 ok got it 2024-07-21 10:09:33 I want to probably host all this on our own registry so we are not depending on docker 2024-07-21 10:09:51 apparently the think loongarch64 is not popular enough, so for the time being, no official images 2024-07-21 10:11:18 nod 2024-07-21 10:11:34 i think our build scripts have an issue 2024-07-21 10:11:37 or im holding it wrong 2024-07-21 10:11:50 which build scripts? 2024-07-21 10:11:56 --hostkeys doesnt do what it says it does 2024-07-21 10:12:06 ./mkimage.sh --profile minirootfs --outdir /home/clandmeter --repository https://dev.alpinelinux.org/edge/main --hostkeys 2024-07-21 10:12:43 --hostkeys Copy system apk signing keys to created images 2024-07-21 10:12:51 ah ok 2024-07-21 10:13:17 i mean this is the most simplest way to create a docker image 2024-07-21 10:13:33 but i dont know why it does not want to add the key 2024-07-21 10:19:57 aha, does only works for images with a kernel... 2024-07-21 10:22:16 clandmeter: there is already a minitrootfs image 2024-07-21 10:22:30 https://dev.alpinelinux.org/~loongarch/edge/releases/loongarch64/ 2024-07-21 10:22:40 i know 2024-07-21 10:22:47 but why not build yourself :) 2024-07-21 10:51:28 i had to hack the genrootfs script to make it work, seems it not that flexible. 2024-07-21 10:54:48 I think ncopa ran into issues with rv64 as well because it didn't have an -lts kernel 2024-07-21 10:55:30 the repo is always set to dl-cdn 2024-07-21 10:55:36 yup 2024-07-21 10:55:38 that as well 2024-07-21 10:55:48 so i think we might need to add an option to change it 2024-07-21 10:55:57 but default to cdn 2024-07-21 10:57:55 rootfs does not ship a kernel, so im not having issues for this part. 2024-07-21 10:58:08 right 2024-07-21 11:09:19 build-base also has hardcoded repo location 2024-07-21 11:11:12 yes 2024-07-21 11:11:51 I manually changed it in the setup script for now, but planned on making it a build argument 2024-07-21 11:13:28 nod 2024-07-21 11:26:06 did something change about the runner registration? 2024-07-21 11:26:10 i remember something 2024-07-21 11:26:56 yes 2024-07-21 11:27:02 you need to register one in advance now 2024-07-21 11:27:08 and provide that token 2024-07-21 11:27:17 can the readme be updated? 2024-07-21 11:27:59 https://tpaste.us/j4rn 2024-07-21 11:28:06 clandmeter: yes 2024-07-21 11:28:27 But not today 2024-07-21 11:28:53 :) 2024-07-21 11:32:45 ikke: create a project runner under aports? 2024-07-21 11:32:57 for what? 2024-07-21 11:33:03 ci? 2024-07-21 11:33:08 oh, no, in admin panel 2024-07-21 11:33:18 shared runner 2024-07-21 11:33:21 otherwise it cannot run in forks 2024-07-21 11:33:27 https://gitlab.alpinelinux.org/admin/runners top right 2024-07-21 11:33:28 ah ok 2024-07-21 11:33:31 found it 2024-07-21 11:34:15 what should the tags be? 2024-07-21 11:36:01 docker-alpine ci-build loongarch64 2024-07-21 11:36:14 yes 2024-07-21 11:37:01 I'm thinking about creating a script that asks for a PAT on stdin and then sets up the runner 2024-07-21 11:37:44 GITLAB_REGISTRATION_TOKEN_DOCKER is not needed? 2024-07-21 11:38:02 Not for now 2024-07-21 11:38:09 nod 2024-07-21 11:38:19 Just focused on aports CI runners 2024-07-21 11:38:38 what about the HOST in comose file? 2024-07-21 11:38:51 thats some local change i guess 2024-07-21 11:39:06 HOST: alpine-builder2 2024-07-21 11:39:27 yes 2024-07-21 11:39:32 For the description 2024-07-21 11:43:27 \o/ 2024-07-21 11:44:01 had to change all the alpinelinux/image references 2024-07-21 11:47:46 ikke: i guess its ok like this? 2024-07-21 11:47:53 any way to give it something to work on? 2024-07-21 11:48:23 make a merge request 2024-07-21 11:48:33 or rerun a pipeline 2024-07-21 11:48:46 but no guarantee it will use your runner unless you pause the others 2024-07-21 11:48:57 ok ill let it like this for now 2024-07-21 11:49:04 will enjoy my sunday a bit 2024-07-21 11:49:08 see it later 2024-07-21 11:49:10 o/ 2024-07-21 12:26:39 ikke: why does my runner not show a version? 2024-07-21 12:28:49 Maybe it takes some time? It does show it if you click through and then runners 2024-07-21 12:28:55 Show details 2024-07-21 12:30:36 Required environment variable $REGISTRATION_TOKEN is not set. 2024-07-21 12:30:40 is that an issue? 2024-07-21 12:32:34 It's a warning 2024-07-21 12:32:41 That's the old style token 2024-07-21 12:34:39 ok 2024-07-21 14:27:41 I see the Loongarch CI run duration for https://gitlab.alpinelinux.org/alpine/aports/-/pipelines/249000/builds went from around 16 minutes to 4.5 minutes with a faster connection (i assume to dev.a.o for installing dependencies like Rust and LLVM, which are large packages) 2024-07-21 14:31:25 That's clandmeters runner 2024-07-21 14:31:42 it's been up for several days, but would like to say it's cool to see the build-loongarch64 element and run button in the ci \o/ 2024-07-21 14:32:55 just tested it with a package, works great 2024-07-21 14:33:00 Yes, i realize that 2024-07-21 14:33:25 which explains why it has a faster connection to dev.a.o :) 2024-07-21 14:33:37 Yup 2024-07-21 14:34:51 Don't tell me you tested it with the giant font-iosevka >_< 2024-07-21 14:35:34 I have not 2024-07-21 14:35:45 mio did 2024-07-21 14:35:54 heh 2024-07-21 14:35:59 ^^" 2024-07-21 14:36:17 was it not supposed to run ... ? ^^" 2024-07-21 14:36:20 Probably a good thing it ran on clandmeters runner, otherwise it wouldn't be so quick 2024-07-21 14:37:27 sorry ^^" 2024-07-21 14:37:35 No problem 2024-07-21 14:37:59 There are 2 Loongarch runners (at least, in 2 locations), the new one has just been onling for a few hours 2024-07-21 14:38:06 online* 2024-07-21 14:38:12 got excited seeing the ci online after all the discussion of it coming 2024-07-21 14:38:20 Haha 2024-07-21 14:41:15 which 2 locations? both in the eu, or ...? 2024-07-21 14:42:20 I think the original is in China, and the new one is in the EU 2024-07-21 14:42:50 and builders could soon be set up in the EU too 2024-07-21 14:43:21 awesome 2024-07-21 14:54:32 dont hammer my ci machine, or i wont be able to pay my energy bills ;-) 2024-07-21 15:03:48 okay ^^" is the machine dedicated to running ci at the moment or have you had a chance to experiment with it a bit? 2024-07-21 15:06:45 mio: It's a desktop computer 2024-07-21 15:07:57 There are pictures on https://fosstodon.org/@ncopa 2024-07-21 15:08:14 ah. yes, pictures please and thanks 2024-07-21 15:12:14 i was just kidding 2024-07-21 15:12:21 you can use this system to do ci 2024-07-21 15:14:36 lol do you have any plans for it yet besides ci? 2024-07-21 15:15:39 looks beefy from n c o p a ' s photos 2024-07-21 15:21:08 probably some dev work on the arch 2024-07-21 15:21:13 if i have time 2024-07-21 15:22:15 cool ^^ 2024-07-21 16:00:20 mio: this is related: https://chipsandcheese.com/2024/03/13/loongson-3a6000-a-star-among-chinese-cpus/ 2024-07-21 16:00:30 maybe its been mentioned before already 2024-07-21 16:03:40 clandmeter: thanks ^^ think A r i a d n e linked to it earlier, but yeah, that article got me interested in hearing other people's experiences of it in daily use 2024-07-21 16:06:53 performance sounds decent out of the gate. would like to see a desktop/pc in a smaller form factor with a loongarch64 chip one day 2024-07-21 16:08:49 this is pretty small 2024-07-21 16:09:01 not nuc size 2024-07-21 16:09:03 but not bad 2024-07-21 16:10:12 yeah, was thinking closer to nuc size, but might have gotten the impression it was larger than it was from the photo, full tower 2024-07-21 16:10:29 no more like a mini tower 2024-07-21 16:10:41 few times bigger than nuc ofc 2024-07-21 16:11:05 harder to ductape to the back of a monitor :) 2024-07-21 16:11:11 lol 2024-07-21 16:13:36 get a larger monitor, problem solved j/j ^^ 2024-07-21 17:29:51 i hope really hope loongarch gets more powerfull and pretty devices, so that they could be a actual competitor 2024-07-21 17:29:55 the more competition in the arch world, the better 2024-07-21 19:32:23 removing the radeon card enables the onboard hdmi 2024-07-21 19:32:40 so that will save some watts never used 2024-07-21 19:37:28 huajingyun: which config did you base your lts config on? 2024-07-22 02:41:17 Ok, the Rust 1.80.0 pre-release/preparation MR (!69243) got clandmeters runner for the Loongarch CI 2024-07-22 02:41:55 Let's see how fast Rust builds with a faster connection to dev.a.o 2024-07-22 02:43:52 If the pre-release succeeds, i can very likely skip CI when the real release is made a few days later, as the tarballs are usually the same, and the one time i noticed it was different, the difference was just a minor one (iirc) 2024-07-22 02:59:02 cely: Ok 2024-07-22 03:00:24 Ah! 2024-07-22 03:00:37 The issue may have been staring at us all this time 2024-07-22 03:00:59 `timeout 3600 make jdk-image` 2024-07-22 03:01:30 So, 1 hour 2024-07-22 03:01:34 which is probably not enough 2024-07-22 03:01:55 That's for openjdk17 2024-07-22 03:02:06 openjdk8 has `timeout 9000` 2024-07-22 03:02:22 So, 2.5 hours 2024-07-22 03:02:26 and maybe that is not enough also 2024-07-22 03:06:22 cely:Did you see these timeout information in the build log? 2024-07-22 03:06:32 No, it's in the APKBUILD 2024-07-22 03:06:40 It doesn't appear in the build log, as far as i know 2024-07-22 03:06:52 Yes 2024-07-22 03:08:06 However, it is a bit weird that you all didn't hit this timeout while building the bootstrap openjdk8 .apk 2024-07-22 03:09:34 and openjdk17 as well, which is even shorter, just 1 hour 2024-07-22 03:10:43 I think this is the first time openjdk17 is being built on the builder, as what's in the dev.a.o/edge repo now was probably carried over from dev.a.o/~loongarch/edge which you manually uploaded 2024-07-22 03:14:29 Looking at the CI runs for openjdk17 and openjdk21, openjdk17 fails after around 85-90 minutes 2024-07-22 03:14:59 where as openjdk21 succeeded after 134 minutes 2024-07-22 03:15:09 and openjdk21 doesn't have `timeout` in its APKBUILD 2024-07-22 03:15:33 So, at least for openjdk17, i think this is probably it 2024-07-22 03:15:38 The timeout needs to be increased 2024-07-22 03:16:28 because openjdk17 is disabled for 32-bit and riscv64 2024-07-22 03:16:52 and usually those archs are slower than the usual x86_64/aarch64 2024-07-22 03:17:11 which is probably why openjdk17's timeout is so short 2024-07-22 03:17:32 Then openjdk21 additionally has riscv64 enabled, and there is no timeout there 2024-07-22 03:18:14 So, i think we should increase the timeout 2024-07-22 03:18:28 Maybe 5 hours 2024-07-22 03:18:30 Yes, I also noticed that openjdk21 does not set timeout 2024-07-22 03:19:17 Do you have the build time for openjdk8 when it built successfully? 2024-07-22 03:19:44 but if it took longer than 2.5 hours, then did you all somehow bypass that timeout while building it locally? 2024-07-22 03:22:12 currently record the time via "time abuild -r" 2024-07-22 03:22:46 That records the time for the whole build though 2024-07-22 03:23:31 The `timeout` in APKBUILD is specifically applied to 1 make command in build() 2024-07-22 03:24:44 timeout 14400 make JOBS="${JOBS:-2}" 2024-07-22 03:25:33 Hehe 2024-07-22 03:25:57 openjdk8 grew to 4 hours and is now trying to compile 2024-07-22 03:27:26 OpenJDK's build times makes Rust look fast :D 2024-07-22 03:30:18 Anyway, just wondering, is there anyone/any team at Loongson working on porting sbcl (Common Lisp compiler) or ghc (Haskell compiler) to loongarch64? 2024-07-22 03:34:12 we have a team working on ghc 2024-07-22 03:34:41 Ok 2024-07-22 03:35:42 I'm not sure about sbcl, but I remember there should be a gcl 2024-07-22 03:36:33 Hmm, i tried to add gcl, but i think it didn't succeed for any arch 2024-07-22 03:37:02 Maybe it has some issues with musl 2024-07-22 03:37:30 Anyway, maybe sbcl will be more interesting :) 2024-07-22 03:38:01 It is enabled for more archs than ghc, and i think for ghc, probably only one or two people actually know how to bootstrap/upgrade it for Alpine 2024-07-22 03:43:33 Ok,I can take some time today to further confirm the status of loongarch64 support for gcl, sbcl and ghc 2024-07-22 03:44:07 Maybe you can take gcl off the list, as it is not even in Alpine repos 2024-07-22 03:45:41 Okay, sure 2024-07-22 03:46:36 For sbcl, we are currently building it with ecl, which as far as i know is enabled for all architectures 2024-07-22 03:47:28 Though building sbcl with ecl gives it build times that are around that of Rust (meaning long, but not too long :D) 2024-07-22 03:48:43 However, if we can build sbcl with sbcl (and use ecl only when building a new release) then it would be fast (though this is a bit out of scope here) 2024-07-22 03:49:53 Anyway, speaking of Rust, the Loongarch CI has finished 2024-07-22 03:50:06 In less than 1 hour 2024-07-22 03:50:11 :) 2024-07-22 03:50:27 That's good :) 2024-07-22 03:51:48 Faster than s390x and ppc64le :P 2024-07-22 03:52:28 :-D 2024-07-22 03:54:29 I'll be going AFK now 2024-07-22 03:54:37 Bye 2024-07-22 06:19:00 cely: Openjdk8 has not been built yet, but the location where the builder reported an error has been built 2024-07-22 06:20:04 Ok, now it passes 2024-07-22 06:21:26 real 3h 5m 40s 2024-07-22 06:23:29 openjdk17 also passed, we need to increase the timeout 2024-07-22 06:25:14 Yes 2024-07-22 06:25:26 So, as i said 5 hours 2024-07-22 06:28:11 Yes,so do we create an MR? Or can you help 2024-07-22 06:28:45 I will do it 2024-07-22 06:29:10 5 hours is definitely enough 2024-07-22 06:29:15 Thank you 2024-07-22 06:36:51 You're welcome, pushed that change 2024-07-22 06:38:22 I think build-edge-loongarch64 just started building OpenJDK8 again about an hour ago 2024-07-22 06:39:14 So, maybe you will want to look into killing that, if you do that, remember to kill the child process so abuild can clean up makedepends 2024-07-22 06:39:41 Probably you should just kill make, which is what timeout does anyway 2024-07-22 06:54:01 OK, have done 2024-07-22 08:33:52 huajingyun: got my msg? 2024-07-22 08:35:15 clandmeter: No, did you send any message? 2024-07-22 08:35:31 yesterday here 2024-07-22 08:35:51 regarding kernel 2024-07-22 08:37:52 Sorry,can you describe it a little more? About the kernel 2024-07-22 08:38:04 the config you used 2024-07-22 08:38:13 did you base it on ours or on another config? 2024-07-22 08:39:56 I assume loongarch has a set of config options that needs to be enabled to work, a minimum config lets say. 2024-07-22 08:40:19 based on main/linux-lts, I didn't modify anything 2024-07-22 08:42:53 sorry,which ones are you referring to? 2024-07-22 08:51:43 Hmmm, i was busy with something else, did the builder get to OpenJDK again? 2024-07-22 08:54:09 cely: No, now blocked on ceph18 2024-07-22 08:54:29 I think the answer is no, the build log for openjdk8 looks truncated (probably as it was killed) 2024-07-22 08:55:13 I think ceph18 is not a dependency of openjdk8, so we can keep retrying until it gets to openjdk again 2024-07-22 08:55:23 and now it has 2024-07-22 08:56:06 But you'll probably be off work 3 hours from now 2024-07-22 08:56:37 Hopefully `timeout` was the only thing that caused problems, and the build completes this time :) 2024-07-22 08:56:40 Same for openjdk17 2024-07-22 08:57:19 I think they will compile successfully 2024-07-22 08:58:49 Just wondering, did you or znley or someone else think about `timeout` before i mentioned it? 2024-07-22 08:58:59 I mean, that it was the cause of the build failure 2024-07-22 09:00:40 Because there is a coincidence here :) 2024-07-22 09:01:21 I also have a few aports (i believe 2) that has blocked the builders before due to the build process hanging, and i copied that technique of using `timeout` to prevent that 2024-07-22 09:02:15 Yes, we initially guessed that it was timeout, but I overlooked that it can be set in APKBUILD 2024-07-22 09:05:48 Yes, this is a solution 2024-07-22 09:06:24 clandmeter: Regarding kernel, I wonder if this solves your doubts? 2024-07-22 09:09:11 ghc depends on llvm15, would you consider upgrading it? For example, upgrading to llvm16 or later 2024-07-22 09:10:04 llvm15 does not support loongarch64 2024-07-22 09:11:50 For that, you'll probably have to ask @nmeum 2024-07-22 09:11:59 He's the one working on ghc 2024-07-22 09:13:05 I wish he will be able to find some time to write up something explaining how ghc is upgraded, but he's probably busy 2024-07-22 09:14:37 Is it difficult to upgrade ghc? 2024-07-22 09:14:59 From what little i've seen, it seem quite involved 2024-07-22 09:15:31 I've seen a name/technique coming up "hadrian" or something, but i only know the name, not sure about the details 2024-07-22 09:15:40 and sometimes, i think it requires building it twice 2024-07-22 09:15:44 it = ghc 2024-07-22 09:16:05 or there're some file format errors, i think 2024-07-22 09:19:11 we are going to try to cross-build ghc based on llvm16 first 2024-07-22 09:22:09 Maybe, if possible, you should write down somewhere the steps you all used :) 2024-07-22 09:23:10 Anyway, ghc is not my department (though i'm interested in learning about it) 2024-07-22 09:23:28 For now, i'm probably more interested in sbcl 2024-07-22 09:24:10 but we'll have to continue this discussion some other time, as i'm going AFK, so bye 2024-07-22 09:24:55 Ok,bye 2024-07-22 09:31:51 the loongarch64 ci is pretty decent 2024-07-22 09:32:39 huajingyun: im asking as i wanted to load configs but the option was disabled 2024-07-22 09:32:59 and i assume all the loongarch stuff is build into the kernel? not as module. 2024-07-22 09:33:36 load configs? 2024-07-22 09:34:25 modprobe configs 2024-07-22 09:34:38 /proc/config.gz 2024-07-22 09:34:41 got it 2024-07-22 09:35:02 so that made me doubth if it was based on lts 2024-07-22 09:35:18 you have also /boot/config-* 2024-07-22 09:35:35 i can see the config also in git 2024-07-22 09:36:02 the point is, is the kernel following our lts or is it its own 2024-07-22 09:36:26 it works for me, so im not complaining, just wondering. 2024-07-22 09:37:05 yeah, i understand, i am lookin for the config knob for modprobe configs 2024-07-22 09:37:22 i suspect its not enabled in the loongarch64 defconfig 2024-07-22 09:38:10 clandmeter: did you compare lts.loongarch64.config and /boot/config-* and find they are different? 2024-07-22 09:38:28 they should be very different 2024-07-22 09:38:48 i think most is also build in? 2024-07-22 09:38:58 lts.loongarch64.config should only have the difference from the defconfig 2024-07-22 09:39:48 kernel config always gives me a headache 2024-07-22 09:39:54 i try to stay away from it 2024-07-22 09:40:37 :) 2024-07-22 09:40:55 CONFIG_IKCONFIG=m and CONFIG_IKCONFIG_PROC=y 2024-07-22 09:41:17 looks like they are missing in the lts.loongarch64.config 2024-07-22 09:44:08 I haven't looked into it for a while since the kernel boots fine on loongarch64 (no issues so far) 2024-07-22 09:44:50 clandmeter: start from default config for particular SoC/CPU 2024-07-22 09:45:25 the problem with defconfig is that its missing a lot of stuff 2024-07-22 09:45:37 from a distro perspective 2024-07-22 09:45:55 when you design a board, you only need a few options/modules extra to get the board working 2024-07-22 09:46:01 ahm, then 'make allyesconfig' :D 2024-07-22 09:46:34 ncopa will not talk to you anymore :p 2024-07-22 09:46:51 ;-) 2024-07-22 09:49:16 do we have LXCs for devs of loongarch64 2024-07-22 09:49:50 sort of, but they are inconveniently far away. high latency 2024-07-22 09:50:00 aha, ok 2024-07-22 09:50:15 hope soon I will have real hardware 2024-07-22 09:52:55 clandmeter: Have you started installing those four servers (Switzerland) this week? 2024-07-22 09:55:01 It is indeed inconvenient.,I have been coordinating the network, but the effect is not obvious 2024-07-22 09:55:06 i am just preparing the router to be shipped to switersland 2024-07-22 09:55:20 should arrive by the end of the week 2024-07-22 09:55:32 hope midasi has time to rack them this week 2024-07-22 09:56:32 Ok,thank you:) 2024-07-22 09:56:49 huajingyun: you have done alot of good work with this! I don't think any other arch we have added has been as pleasant as loongarch64 2024-07-22 09:57:06 ncopa: I fully agree 2024-07-22 09:57:33 huajingyun: we appreciate the work you do. thank you very much! 2024-07-22 09:57:51 +1  2024-07-22 09:58:15 uh s//^/ 2024-07-22 10:04:45 Thank you! I am very happy to receive your support and affirmation:-D 2024-07-22 10:04:54 hope Alpine can develop better 2024-07-22 10:07:03 Alpine is best ;-) (not better) 2024-07-22 10:08:00 Yes,fully agree:-D 2024-07-22 10:13:42 but we can always do better 2024-07-22 10:16:49 or worse 2024-07-22 12:02:43 huajingyun: do you have any technical information about the systems? 2024-07-22 12:02:55 like for instance what is the max memory it can handle 2024-07-22 12:23:27 Will probably get your answer tomorrow 2024-07-22 12:23:38 Anyway, it seems openjdk8 built successfully :) 2024-07-22 12:35:48 🎉 2024-07-22 12:37:07 yeah im used to it, working for asian companies :) 2024-07-22 12:39:42 so the ci box is not bad 2024-07-22 12:40:01 compared to other arches, its faster or a little slower compared to ie x86 2024-07-22 12:40:39 it feels much more mature comapred to rv64 2024-07-22 12:52:58 indeed 2024-07-22 12:53:15 did kernel compile on loongarch64. took 23 mins 2024-07-22 12:53:26 depends on kernel config, but still. that is not bad 2024-07-22 12:55:49 so the servers have the same cpu? 2024-07-22 12:55:54 I cant find much about it 2024-07-22 13:00:10 i think the servers has bigger CPUs 2024-07-22 13:05:13 3A6000 only has 4 cores 2024-07-22 13:06:21 and wikipedia does not list a bigger one 2024-07-22 13:06:31 not sure if they have dual socket support 2024-07-22 13:07:19 https://github.com/loongson/Firmware/tree/main/5000Series/Server/LS4C5LG 2024-07-22 13:07:24 this looks more powerfull :) 2024-07-22 13:08:09 https://build.alpinelinux.org/buildlogs/build-edge-loongarch64/testing/pfetch-rs/pfetch-rs-2.10.0-r0.log 2024-07-22 13:09:00 Hmm, but that only lists memory and number of packages 2024-07-22 13:10:54 From CI output: https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1460351 ("Number of Cores: 32") 2024-07-22 13:14:19 and finally from the very first IRC log: https://irclogs.alpinelinux.org/%23alpine-loongarch-2024-01.log 2024-07-22 13:14:33 "CPU: 3C5000*2 (16cores*2)" 2024-07-22 13:18:30 openjdk17 has also built successfully :) 2024-07-22 13:31:48 ah and i replied 2024-07-22 13:32:24 that will be beefy 2024-07-22 15:30:52 thats lovely 2024-07-22 16:41:35 Just pushed a commit that i'm not really proud off, but i think i don't want loongarch64 blocked at community/ for so long 2024-07-22 16:42:27 especially as upload is (for now) not as fast as the other builders 2024-07-22 17:19:32 Anyway, maybe sort of to compensate for that hackish commit, i think i may have found the missing rebuild that will unblock ceph17/18 2024-07-22 17:20:25 I'm about to go AFK, so i'm debating whether to just push it without waiting for CI on all archs 2024-07-22 17:20:49 After all, it is just an additional pkgrel bump, and community/ is already blocked anyway 2024-07-22 17:21:00 which is it? 2024-07-22 17:21:07 apache-orc 2024-07-22 17:21:42 I wonder how that is relevant 2024-07-22 17:22:28 (Not that I don't believe you, just curious) 2024-07-22 17:22:49 I think i just got confirmation from x86_64 that it works: https://gitlab.alpinelinux.org/Celeste/aports/-/jobs/1460491 2024-07-22 17:23:11 apache-arrow depends on apache-orc 2024-07-22 17:24:22 and while googling around for the error message, i found a mention of apache-orc (closed that page now though) 2024-07-22 17:24:39 interesting 2024-07-22 17:24:55 Will leave it up to the C++ people to sort out what exactly happened 2024-07-22 17:25:05 Huh, my snippet to check for which packages need to be rebuilt for apache-orc lists 10k packages 2024-07-22 17:25:28 but it can go into the knowledge base now: if apache-arrow errors out with some abseil/protobuf thing, try a rebuild apache-orc 2024-07-22 17:25:31 of* 2024-07-22 17:25:45 I say push it 2024-07-22 17:26:05 Ok 2024-07-23 00:53:38 An error occurred during compile ghc on loongarch64-alpine. 2024-07-23 00:53:42 Currently only 11 up to 16 (non inclusive) is supported. System LLVM version: 16.0.6 2024-07-23 00:55:02 At least we need a version of ghc that compatible with llvm16. 2024-07-23 01:15:17 clandmeter: Ok, I think you should be more concerned about the server machines now,i will confirm the information you mentioned:) 2024-07-23 01:32:40 How about sbcl, any news on that? :) 2024-07-23 01:39:25 I asked about sbcl yesterday, but there is no new information yet 2024-07-23 01:50:36 Ok, thanks 2024-07-23 01:53:11 You're welcome. I'll let you know when have news 2024-07-23 02:05:47 That's great 2024-07-23 02:53:56 clandmeter:Here are some important specs of the server (in Switzerland): 2024-07-23 02:54:09 CPU: 3C5000*2 (16 cores*2=32 cores) 2024-07-23 02:54:09 Memory: 32G*8=256G (I mentioned 128G before, we increased it on these servers in Switzerland) 2024-07-23 02:54:09 Disk: nvme, 256G 1sata, 4TB 2024-07-23 02:54:58 you mentioned the max memory, 3C5000 supports 8 RDIMM slots, a single memory supports 16GB/32GB/64GB, the max memory capacity will be 512G. 2024-07-23 02:56:57 It should be noted that the CPU of the PC machines is 3A6000, while the server is 3C5000. When the 3C6000 server is released, it will become more powerful 2024-07-23 03:57:27 Oh wow 2024-07-23 03:57:39 It seems we have both community/java-sigar and community/sigar 2024-07-23 03:58:13 (I'm looking through openjdk aports to see which can be enabled on Loongarch) 2024-07-23 04:58:37 Is anyone here? 2024-07-23 04:59:03 I think openjdk8-bootstrap hasn't been removed from the builder 2024-07-23 04:59:53 So, somethings that succeed in CI, don't succeed on the builder 2024-07-23 05:00:12 Thankfully out of the 7 aports i've enabled so far, only testing/eclipse-ecj is affected by that 2024-07-23 05:14:29 cely: removed openjdk8 2024-07-23 05:14:49 Thanks 2024-07-23 06:00:45 Thanks 2024-07-23 06:11:18 With Clojure enabled, i have finished working through the list of Java aports i wanted to enable :) 2024-07-23 06:15:43 How many aports 2024-07-23 06:35:00 cely: about sbcl, loongarch64 is not supported upstream, but one of our colleagues is planning to port it. 2024-07-23 06:38:59 That's good news 2024-07-23 06:40:27 I've enabled 12 Java aports: apache-ant, maven, java-jffi, java-jna, java-lz4, eclipse-ecj, java-jtharness, ma1sd, spark, sonar-scanner, openfire, clojure 2024-07-23 06:42:10 Yes, I'll let you know when there's new progress, but it might take a while. 2024-07-23 06:43:11 Great:-DThanks! 2024-07-23 06:43:18 Alright, no problem 2024-07-23 06:44:02 By the way, i noticed that main/efibootmgr is enabled for 6 archs, but not Loongarch 2024-07-23 06:44:22 Maybe you will want to have a look if it works 2024-07-23 06:44:43 (it lists all the archs explicitly, instead of using "all" and then excluding those where it doesn't work) 2024-07-23 06:45:22 Ok,no problem 2024-07-23 06:45:36 I will take a look 2024-07-23 06:50:32 cely: main/efibootmgr passed 2024-07-23 06:56:38 Yeah, i mean if it does its function on Loongarch 2024-07-23 06:57:16 Not sure why there are some aports that lists archs explicitly 2024-07-23 06:57:48 Well, actually, i think i have one or two like that, but i add the reason the other archs are not enabled 2024-07-23 06:58:07 efibootmgr doesn't, so we are left guessing 2024-07-23 07:02:18 cely: if a project specifically supports certain arches, it makes more sense to list them instead having to disable every other arch 2024-07-23 07:05:26 I know 2024-07-23 07:05:44 but i've seen one or two that lists archs explicitly, then say "64-bit only" 2024-07-23 07:05:46 :) 2024-07-23 07:07:08 and now we have a new 64-bit arch 2024-07-23 07:09:12 and then i just saw one that lists 7 archs 2024-07-23 07:09:18 s390x excluded 2024-07-23 07:09:25 I guess this is the little endian group 2024-07-23 07:09:38 huajingyun: thats what i wanted to ask next :) 2024-07-23 07:09:52 what is the performance diff between the chips per core 2024-07-23 07:10:06 6000 is a huge step i think? 2024-07-23 07:12:10 cely: yes, I'm wondering if there is any easy way to verify it 2024-07-23 07:12:25 huajingyun: could I PM you? 2024-07-23 07:12:27 clandmeter: yes,a huge step 2024-07-23 07:13:12 mps: of course, welcome:) 2024-07-23 07:39:08 kstars is having that KDE mirror 403 problem again 2024-07-23 08:04:12 Oh, it might be network . I'll check now 2024-07-23 08:06:09 I think we have always worked around this issue by either making the files available on distfiles.a.o (i think this is automatically sync'ed, but that gives it a delay), or maybe you've manually added the files to /var/cache/distfiles once or twice before 2024-07-23 08:48:21 I just uploaded this tarball 2024-07-23 08:48:32 That's good 2024-07-23 08:48:41 It's already retrying :) 2024-07-23 08:51:40 It should be fine now 2024-07-23 08:52:00 Ok 2024-07-23 09:06:51 Now tests fail with "Failed opening user database /home/buildozer/.qttest/share/testksuserdb/userdb.sqlite" (probably due to "duplicate connection name"?) 2024-07-23 09:07:01 algitbot: retry master 2024-07-23 09:07:08 (kstars) 2024-07-23 09:08:49 Hmm, but it may also look like a timeout 2024-07-23 09:09:08 Yes, "test function timed out" :/ 2024-07-23 09:25:23 Hopefully this time it will pass, the network looks a bit bad today 2024-07-23 09:46:45 Still failed due to timeout 2024-07-23 09:49:44 The local machine check has passed, so kstars is fine, but the builder's network 2024-07-23 09:54:51 So, it downloads something for the tests? 2024-07-23 09:55:03 (star catalogs, perhaps) 2024-07-23 09:55:41 I think i'll just disable tests with a note to retry them when builder is set up in EU 2024-07-23 10:16:17 Ok, skipped TestKSUserDB on loongarch64 2024-07-23 10:16:24 Hopefully that will allow it to pass now 2024-07-23 10:16:30 I'll be going AFK, so bye 2024-07-23 10:58:26 cely: Ok,thank you 2024-07-23 12:55:53 I think in the end it passed without needing to skip that test 2024-07-23 12:55:54 lol 2024-07-24 01:11:41 :) 2024-07-24 09:16:10 It's a quiet day.. 2024-07-24 09:28:26 not now ;-) 2024-07-24 09:30:44 Two messages (three now) is still rather quiet :) 2024-07-24 09:40:26 Haha, add one more 2024-07-24 09:41:17 should also say \o/ so the bot can join in :D 2024-07-24 09:44:32 w00t 2024-07-24 09:44:45 Do you know how to connect to irc.libera.chat? My colleague wants to join #ghc but he can't. 2024-07-24 09:45:00 https://gitlab.haskell.org/ghc/ghc/-/wikis/mailing-lists-and-irc 2024-07-24 09:46:38 qaqland may know, he's mentioned before that you need SASL enabled 2024-07-24 09:48:51 Ok, thanks 2024-07-24 09:49:23 Googled for "china libera sasl" and got: https://emacs-china.org/t/irc-connection-failed/26929 2024-07-24 09:50:58 nice, this might help 2024-07-24 09:54:07 Though that's Emacs, so you still need to find out how to configure SASL for the IRC client you all are using 2024-07-24 09:55:52 Ok,thank you very much 2024-07-24 09:55:58 You're welcome 2024-07-24 10:04:53 I'll be going AFK 2024-07-24 10:05:11 Bye 2024-07-24 13:22:28 is a quiet day not a good thing? calm before chaos? 2024-07-24 13:25:31 Haha 2024-07-24 13:29:32 ^^ how is everyone doing? 2024-07-24 13:31:08 I'm alright 2024-07-24 13:32:19 How about you? 2024-07-24 13:34:52 good here. just put alpine on a raspberry pi 3, will try to use it as a little abuild/dev device 2024-07-24 13:38:12 Don't try to build chromium:-p 2024-07-24 13:38:55 lol ... will try to build wesnoth instead :D 2024-07-24 13:40:00 which is slightly better than font-iosevka on the package fetch front? should take not much time on x86_64, don't know for the pi 2024-07-24 13:40:06 Is it the 1gb RAM model? 2024-07-24 13:40:45 yes 2024-07-24 13:41:21 get some use out of an existing device first before coming up with an excuse to get a new one lol 2024-07-24 13:41:40 :P 2024-07-24 13:42:31 time to build measured in cups of coffee made 2024-07-24 13:42:40 and consumed 2024-07-24 14:06:16 this channel is not as quiet as -arm :P 2024-07-24 14:10:21 f_: there is #alpine-arm channel? 2024-07-24 14:10:38 mps: apparently 2024-07-24 14:10:45 as the newest arch to join, this channel gets more action maybe 2024-07-24 14:11:16 hm, why no one informed me 2024-07-24 14:11:29 lol didn't know there was an active alpine arm channel either ^^ 2024-07-24 14:11:43 is it on OFTC 2024-07-24 14:11:47 yeah 2024-07-24 14:11:56 * ChanServ: Time Registered: Sat 24 Feb 2024 12:00:14 +0000 (5m 0d 02:11:04 ago) 2024-07-24 14:11:56 * ChanServ: Channel information for #alpine-arm 2024-07-24 14:11:56 * ChanServ: Description: Alpine Linux ARM development 2024-07-24 14:11:56 * ChanServ: Channel is currently in use. 2024-07-24 14:12:07 you can use /list alpine-* to see all alpine channels 2024-07-24 14:12:39 or https://irclogs.alpinelinux.org/ to see all offical ones 2024-07-24 14:13:16 so -arm isn't official? 2024-07-24 14:13:36 I've no idea (cc ikke) 2024-07-24 14:14:05 that might be why hadn't noticed aside from the -riscv64 one 2024-07-24 14:15:18 didn't see it on irclogs.a.o 2024-07-24 14:18:30 Because we didn't make algitbot join there, and there hasn't been any discussion anyway 2024-07-24 14:19:05 Except for just now 2024-07-24 14:20:40 not sure we need all these $arch channels 2024-07-24 14:21:09 #alpine-devel is enough 2024-07-24 14:21:37 IMO, ofc 2024-07-24 14:21:53 but you aren't in #alpine-devel :P 2024-07-24 14:21:59 lol 2024-07-24 14:22:01 and neither am i 2024-07-24 14:22:04 Hahaha 2024-07-24 14:22:07 cely: hehe I know ;-) 2024-07-24 14:22:59 craete #alpine-for-harsh-people channel and I will join :-) 2024-07-24 16:03:35 ikke: Fair 2024-07-25 17:07:51 what's the status of !64260 ? the package could use a rebuild for python 3.12. have a patch to fix the display test but don't want to step on others' efforts 2024-07-25 17:09:08 didn't try to switch to gpep517 yet locally. there's a comment about test failing on loongarch64, wonder if it's the same test or a different one 2024-07-25 17:10:52 I'm semi-AFK, but i'll give a quick answer 2024-07-25 17:10:57 was looking to run castero locally and ran into the issue ^^" 2024-07-25 17:11:41 @omni has been busy lately, and will very likely not mind you working on this 2024-07-25 17:12:13 okay, thanks ^^ 2024-07-25 17:13:37 As for the test that failed on Loongarch, you may see the log here: https://build.alpinelinux.org/buildlogs/build-edge-loongarch64/testing/castero/castero-0.9.5-r2.log 2024-07-25 17:14:40 It seems to be 2 display tests, and 1 download test (which may be a builder network issue) 2024-07-25 17:19:53 the display tests also fail for x86_64 now. not sure if could do anything about the download test 2024-07-25 17:20:25 thanks for the log link 2024-07-25 17:22:46 You're welcome 2024-07-25 17:22:47 AFK for real now, bye 2024-07-25 17:27:43 bye! 2024-07-27 11:53:22 Another quiet weekend.. 2024-07-27 11:53:33 I like quiet weekends 2024-07-27 11:53:50 Yesterday a lot of MRs were opened 2024-07-27 11:53:57 Really? 2024-07-27 11:54:25 I'm actually not really talking about Gitlab, but instead this IRC channel 2024-07-27 11:54:33 52 opened, 25 merged (closed are not counted) 2024-07-27 11:54:38 yeah 2024-07-27 11:54:40 understood 2024-07-27 11:55:44 Too bad Qt6 WebEngine is still not behaving properly on 32-bit 2024-07-27 12:01:51 sadface 2024-07-27 12:13:29 ikke: thanks for merge 2024-07-27 12:14:21 cely also does a lot of work 2024-07-27 12:15:46 yes, thanks cely and anyone else on the review team haven't mentioned ^^ 2024-07-27 12:17:34 You're welcome 2024-07-27 12:18:47 this channel has been quieter since the ci and builders came online? 2024-07-27 12:19:18 maybe fewer packages to fix and request to verify manually? 2024-07-27 12:19:48 Mostly because bulk of the work has been done already 2024-07-27 12:21:16 yeah 2024-07-27 12:36:18 quick poll: when debugging builds outside of aports ci, do people here prefer to use a qemu, lxc, docker container, chroot, bare metal, none of the above? 2024-07-27 12:37:33 Probably depend on whether you're debugging for a native arch or something else 2024-07-27 12:40:36 for native arch previously used a basic chroot script, haven't emulated arch with a vm. lately experimenting with docker, just curious what other people prefer for various reasons 2024-07-27 12:40:55 say native arch? 2024-07-27 12:41:10 though it would be cool to be able to cross compile to loongarch64 somehow ^^" 2024-07-27 12:42:19 docker or lxc 2024-07-27 12:49:25 cool. was thinking about lxc as well. will probably test a bit to see which one(s) have lower overhead 2024-07-27 15:50:20 Hmm, just spent 3 hours chasing something that didn't turn out to work, whatever 2024-07-27 16:03:40 knowing something didn't quite work could still be a clue for next time 2024-07-27 16:04:38 but yeah, it happens to me sometimes, spending hours on an idea that didn't go anywhere 2024-07-28 04:21:48 ACTION is trying the latest GCC 14 snapshot from yesterday in CI 2024-07-28 04:21:50 Wish me luck 2024-07-28 04:31:04 I probably should've chosen a mirror closer to the Loongarch CI, it seems it's going to take half an hour (or more) to fetch that 84MB tarball from gcc.gnu.org :( 2024-07-28 04:33:50 By then, most likely x86* will have finished, hopefully i get good news from that 2024-07-28 12:58:25 gl 2024-07-28 16:03:57 I wonder if we have enough resources to deal with all the aports that will fail to build with GCC 14 2024-07-28 16:06:13 Do we expect more breakage than usual? 2024-07-28 16:06:55 I think so, i think some things that were formerly warnings are now errors 2024-07-28 16:07:28 Like the printf security thingy? 2024-07-28 16:07:50 More like implicit function declaration 2024-07-28 16:07:56 ah right 2024-07-28 17:01:37 The GCC 14 error i am staring at right now: "error: passing argument 2 of 'bind' from incompatible pointer type [-Wincompatible-pointer-types]", "note: expected 'const struct sockaddr *' but argument is of type 'struct sockaddr_un *'" (from DirectFB) 2024-07-28 17:02:44 but i'm trying to find out why DirectFB segfaults, so i'm just going to build it with GCC 13 for now 2024-07-28 17:12:42 Debian notes another -Wincompatible-pointer-types error (in the nvidia gfxdriver, which we aren't building): https://bugs.debian.org/1074913 2024-07-29 03:15:34 !69862 2024-07-29 03:25:51 Interestingly, i just merged a Links upgrade that fixes GCC 14 issues with its configure script 2024-07-29 05:25:09 Tried a few aports at random, and so far only 1 has failed to build (main/screen), but i'm trying mostly simple/still-maintained aports 2024-07-29 05:25:14 still-maintained-upstream* 2024-07-29 06:12:53 Found another two: main/linux-pam and community/signify 2024-07-29 08:07:59 cely: Are you rebuilding all aports based on gcc14? 2024-07-29 09:52:39 No 2024-07-29 09:52:53 I said "tried a few at random" :) 2024-07-29 09:58:28 I don't really know if anyone is going to systematically try rebuilding all aports with the new GCC 2024-07-29 09:59:12 I think for most GCC upgrades, they've just been merged into edge, and then worked on there (also, for stable main/ and community/ will be rebuilt) 2024-07-29 10:01:17 So, hopefully it gets into edge not too close to 3.21, so people have more time to work on the issues it brings 2024-07-29 10:06:29 Yes, agree 2024-07-30 05:07:15 It seems an RC for GCC 14.2.0 has been released 2024-07-30 05:35:39 It seems upstream plans to release 14.2 on Thursday 2024-07-30 06:18:12 It seems that I haven’t seen some information about 14.2 yet 2024-07-30 06:18:28 cely:Do you have any relevant links? Thanks 2024-07-30 06:28:19 It's in the mailing list: https://gcc.gnu.org/pipermail/gcc/2024-July/244501.html 2024-07-30 06:30:43 It probably won't differ much from the snapshot currently in my MR, so it should hopefully also build successfully on Loongarch 2024-07-30 06:35:51 OK, I think your MR patch for loongarch64 still needs to be used 2024-07-30 06:35:58 I'll take note and verify it again after release 2024-07-30 06:39:43 Ok, thanks 2024-07-30 06:51:17 You're welcome 2024-07-31 04:50:49 so, the motherboard i bought has arrived and i have booted to UEFI successfully and turned off secure boot 2024-07-31 04:50:57 is there like an ISO anywhere i can boot 2024-07-31 04:54:34 https://dev.alpinelinux.org/~loongarch/edge/releases/loongarch64/ 2024-07-31 04:54:51 Is it the same as https://dev.alpinelinux.org/edge/releases/loongarch64/ ? 2024-07-31 04:55:13 I guess so because ncopa synced it 2024-07-31 04:55:26 But they are not generated on the builder 2024-07-31 04:55:56 Ok 2024-07-31 07:04:38 Yes, and this ISO was created on June 25th and also requires an apk upgrade