2024-10-01 01:47:19 huajingyun: fix in !72792 2024-10-01 01:49:04 It's been merged 2024-10-01 01:49:27 Thanks to J0WI 2024-10-01 04:40:04 7 packages remaining 2024-10-01 04:42:02 Most with open MRs 2024-10-01 04:42:05 6 ... "why is it always xsane" :) 2024-10-01 04:42:12 so haven't cycled the builder 2024-10-01 04:45:15 the main one left to unblock is dnssec-tools, asteroid-launcher is already bundled in the asteroid-* MR but it may take a few days for maintainer to complete it 2024-10-01 04:47:04 lipstick-asteroidos in the same MR is already temporarily disabled on loongarch64, if need be could ask for the same with asteroid-launcher 2024-10-01 04:47:51 the other 4 as cely said have MRs pending 2024-10-01 04:48:31 apt-dater cri-o libretro-daphne xsane 2024-10-01 22:21:22 last one needed to unblock testing/ is in the MR queue 2024-10-02 11:50:09 the build-edge-loongarch64 is done! \o/ 2024-10-02 12:16:27 \o/ 2024-10-02 12:17:37 now can change /etc/apk/repositorirs to CDN 2024-10-02 12:37:10 and we can decomission the build-edge-tmp-loongarch64 2024-10-02 13:51:28 \o/ 2024-10-02 16:02:03 Would now be the time to remove `allow_failure: true` for the Loongarch CI? 2024-10-02 16:02:19 probably yes 2024-10-02 17:03:17 New fortify-headers broke Rust again: https://gitlab.alpinelinux.org/Celeste/aports/-/jobs/1541687 2024-10-02 17:05:18 As usual, ppc64le seems unaffected, and this time, s390x also seems unaffected 2024-10-02 17:05:40 I have a very strong suspicion that fortify-headers isn't being applied at all to ppc64le 2024-10-02 17:24:06 but that's for tomorrow 2024-10-02 17:24:10 Going AFK now, bye 2024-10-02 17:27:38 o/ 2024-10-02 17:40:54 which is the PR for that job? 2024-10-02 17:42:49 Back for a very short while, there is no PR, it is upgrade-rust-1.82 (the next release) on my fork of aports 2024-10-02 17:43:04 i pushed update to fortify-headers 2024-10-02 17:43:17 celie: how is the pipeline triggered? For aports we only have pipelines for MRs 2024-10-02 17:43:39 Through glab 2024-10-02 17:44:46 I figured out an incantation for that a while ago, can give it to you tomorrow, if you're interested 2024-10-02 17:44:51 ok 2024-10-02 17:45:30 Curious how that works, because everything assumes there is an MR 2024-10-02 17:45:40 Anyway, i think rebuilding main/rust should also give you the same error, though maybe something could've changed as Rust 1.82 vendors LLVM19 2024-10-02 17:48:04 From memory, it is https://manpages.debian.org/unstable/glab/glab-ci-run.1.en.html with some --variables set 2024-10-02 17:48:35 Ok, AFK for real now, bye 2024-10-02 17:48:50 aha, ok, so you then provide something like CI_MERGE_REQUEST_TARGET_BRANCH_NAME manually 2024-10-02 18:29:50 ncopa: i guess you could add edge to releases.json? 2024-10-02 18:30:11 i guess i could 2024-10-02 18:30:22 reason is that the new pkgs.a.o looks at that 2024-10-02 18:30:29 pkgs should then auto update 2024-10-02 18:30:38 i hope :) 2024-10-02 18:36:27 pushed new alpine-releases.conf.yaml 2024-10-02 18:38:22 thx, lets see in a couple of minutes 2024-10-02 18:38:36 well it will take a bit longer to process all pkgs 2024-10-02 18:48:34 yup, loongarch is popping up on pkgs.a.o 2024-10-02 18:48:39 nice 2024-10-02 18:49:14 now i just hope it finished without errors 2024-10-02 18:49:23 cause the logic is not perfect for larger updates 2024-10-02 18:49:33 but similar to previous 2024-10-02 18:50:38 ikke: fyi, if the update is partially failed, you could set update to true in the config. and it will not check the apkindex version and process the whole index again. 2024-10-02 18:50:54 ok, good to kn ow 2024-10-02 18:51:27 its not a big issue, cause when the index does get an update, it will continue where it was 2024-10-02 18:52:37 oh this is not infra channel. 2024-10-03 01:08:07 Am i seeing this right, and the ppc64le builder is idle? That's why i suspect fortify-headers is not being applied on that arch, as i've seen many times that it is unaffected when other archs are erroring out on fortify.. 2024-10-03 01:25:05 ikke: (Regarding `glab ci run`) Yes, i'm manually specifying that through --variables-env, along with CI_MERGE_REQUEST_PROJECT_URL and CI_PIPELINE_SOURCE 2024-10-04 13:53:19 It would be nice to have !72509 in Alpine 3.21 2024-10-04 13:56:12 +1 2024-10-04 13:56:29 cely: feel free to set milestones for things we should try get included in 3.21 2024-10-04 13:59:42 Ok 2024-10-07 03:23:14 are there any plans to implement STRICT_KERNEL_RWX on loongarch? 2024-10-07 03:25:29 looking at the risc-v implementation it shouldn't be too difficult to accomplish 2024-10-07 21:12:45 lld 19.1.1 seems to be broken on loongarch64: https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1548406 2024-10-08 00:46:24 Could it be because scudo-malloc 18 is used? 2024-10-08 00:47:59 I tried LLVM 19 release candidates, but can't remember how far i went (if i tried lld19) 2024-10-08 00:48:21 I'll try to check my work in a moment 2024-10-08 01:11:13 Hmm, that was a month ago, and i can't remember what i was doing now :( 2024-10-08 01:13:24 Hmm, it seems checks fail, so i didn't manage to get them to pass 2024-10-08 01:14:34 Good morning, I'm back from vacation. 2024-10-08 01:14:42 Thanks to everyone for your hard work, loongarch64 has made such great progress, and testing is also completed, great! 2024-10-08 01:15:06 qaqland: Thanks for fixing git-interactive-rebase-tool 2024-10-08 01:17:32 cely:Did you pass lld19 before because you disabled the check for it? 2024-10-08 01:18:36 No, it didn't pass 2024-10-08 01:18:45 Checks fail, even with scudo-malloc 19 2024-10-08 01:20:46 those tests are failing with exit code 132 2024-10-08 01:20:53 subtract 128 2024-10-08 01:21:22 SIGILL 2024-10-08 01:21:35 so... could be alignment, could be vectors, could be FORTIFY 2024-10-08 01:22:42 FORTIFY i think is SIGTRAP on loongarch 2024-10-08 01:22:45 let me verify 2024-10-08 01:23:17 yes, SIGTRAP 2024-10-08 01:23:25 so, that leaves alignment and vectors 2024-10-08 01:30:21 huajingyun: do you know if there are any plans inside loongson to implement STRICT_KERNEL_RWX support? it would be a good thing to do as it enforces kernel-level write-xor-execute 2024-10-08 01:30:39 (userspace W^X is already covered in openpax kernel patch) 2024-10-08 01:38:56 Maybe it is vectors, what have we done regarding this so far? 2024-10-08 01:40:18 I know a patch for musl was added, but what else needs to be done? 2024-10-08 02:01:40 Building with GCC works, tests pass, so it seems building lld19 with clang19 causes it to use illegal instructions 2024-10-08 02:15:05 Ariadne: Yeah, STRICT_KERNEL_RWX is not supported yet, and i checked and there are no plans to support STRICT_KERNEL_RWX for loongarch64 in the near future due to other development work being done by the kernel team. 2024-10-08 02:47:36 huajingyun: i'm happy to help with it 2024-10-08 02:48:43 though at the moment i am getting ready to port coreboot 2024-10-08 02:49:02 (my goal is to replace the loongson firmware with fully open source one) 2024-10-08 02:53:10 coreboot + loongarch = reasonably priced entirely libre compute option 2024-10-08 02:53:56 Have you come across the repo for the current firmware (or maybe it is better for you not to look at it)? 2024-10-08 02:57:45 Well, it's just the firmware binaries 2024-10-08 02:58:06 Anyway, lld tests may be solved by upgrading CI runners to a kernel with LSX/LASX enabled 2024-10-08 02:59:48 !70603 was the MR that enabled it 2024-10-08 02:59:59 yeah i think it's the issue 2024-10-08 03:00:32 Ariadne:That would be great, we would really appreciate your help with this 2024-10-08 03:01:46 CI needs to upgrade the kernel, and tmp-builder also needs 2024-10-08 03:02:38 tmp-builder should be decommissioned and reallocated as a porterbox or similar imo 2024-10-08 03:03:05 the official builder has fully rebuilt the distro 2024-10-08 03:14:33 Yes, it is indeed not necessary to repeatedly build aports in tmp-builder 2024-10-08 03:14:44 However, we can consider using tmp-builder to build some new aports (not yet integrated into edge), such as ghc, cely has made a lot of efforts for this before. I think I really need to save these processes and results. 2024-10-08 03:15:00 In the future, there may be some new aport that may not pass on all architectures and cannot be integrated into edge for the time being. Maybe we can verify and save these results here in advance 2024-10-08 03:25:20 yeah that is what i mean by porterbox :) 2024-10-08 03:25:30 a machine that developers without a loongarch machine can use 2024-10-08 03:25:54 though, it's fairly easy to buy loongarch machines now with aliexpress and others 2024-10-08 04:07:23 Ariadne: we already have a dev server for loongarch64 2024-10-08 07:53:38 morning! welcome back huajingyun! hope you had a good vacation 2024-10-08 07:53:50 cely: thanks for the scudo-malloc pointer. will fix that 2024-10-08 07:59:22 ncopa:Thank you,i may upgrade the kernel for tmp-builder later to enable LSX/LASX 2024-10-08 08:46:36 I think we can decommision tmp-builder 2024-10-08 08:51:06 build-edge-loongarch64 runs 6.6.47-0-lts 2024-10-08 09:04:33 Are we planning to make llvm19 the default LLVM for Alpine 3.21? 2024-10-08 09:08:14 that is what I am hoping for yes 2024-10-08 09:08:24 that is what I am working on currently 2024-10-08 09:08:46 Maybe we can coordinate that with !73208, which is why i looked at the release candidates in the first place 2024-10-08 09:08:54 Added support for LSX/LASX in 6.6.46-r1, so build-edge-loongarch64 looks good, but the CI machine may also need to be upgraded(cely helped confirm) 2024-10-08 09:09:28 ah, will try to find the ci machine and upgrade that. asap 2024-10-08 09:10:03 Rust 1.82.0 will be released on the 17th 2024-10-08 09:10:24 but a pre-release is usually available the Monday before (14th) 2024-10-08 09:12:21 Though i don't really think using LLVM19 will remove the need for the 32-bit ARM workaround, nor the f16 patch 2024-10-08 09:13:48 Anyway, this will probably have some consequences for Firefox too 2024-10-08 09:16:25 As in, very likely, llvm19 being made default LLVM, Rust switching to llvm19, and then Firefox getting built with that Rust all need to be coordinated 2024-10-08 09:16:46 lets discuss that in #alpine-devel 2024-10-08 09:17:06 or in #alpine-rust 2024-10-08 09:21:35 ncopa:Thanks 2024-10-08 09:21:57 We might consider using this machine(tmp-builder) to build packages that are not currently in edge, just like I mentioned cely's efforts on loongarch ghc, so as to preserve some processes and results 2024-10-08 09:22:07 I have some discussions with cely, this is a preliminary idea at present, and there is no specific way to do it. 2024-10-08 09:22:25 So I think we can take tmp-builder offline for now, and wait until everyone discusses and decides on this matter again, and we decide to enable it again or not. 2024-10-08 09:23:47 So I just power it off, and thats it? 2024-10-08 09:27:10 ncopa:I think for now it might just be necessary to remove in build.alpinelinux.org 2024-10-08 09:35:03 ok 2024-10-08 09:40:45 Thanks 2024-10-08 18:46:45 cely: the 14th is a bank holiday in the US, so the rust release may be delayed until 15th 2024-10-08 19:38:23 FYI, both CI hosts are running 6.6.54-0-lts now 2024-10-09 00:58:39 ikke: Thanks 2024-10-09 01:28:53 Ok, but the Rust 1.82.0 release is actually scheduled for the 17th, 14th is just for the pre-release 2024-10-09 02:37:42 Jingyun has brought the tmp builder machine offline, so i think all that's left is to remove the retained message from the build/build-edge-tmp-loongarch64 MQTT topic so it stops showing up on build.a.o 2024-10-09 02:42:46 Yeah, just shut down the machine, but I forgot to stop mqtt-exec.aports-build, so I'll need to do that later. 2024-10-09 05:01:39 huajingyun: no, that's not necessary. mqtt retains the message like cely mentioned, and the build status backend caches it as well 2024-10-09 05:04:13 ikke: I just rebooted the machine and now I have executed 'rc-service mqtt-exec.aports-build stop' in lxc (build-edge-tmp-loongarch64) 2024-10-09 05:04:53 Is there anything else we need to do? 2024-10-09 05:07:34 There is no explicit support to remove a builder, it needs to be done manually 2024-10-09 05:09:58 I removed it from mosquitto now 2024-10-09 05:16:08 restarted builder-server-status, the builder is now no longer mentioned 2024-10-09 05:32:28 Maybe you should do `rc-update del mqtt-exec.aports-build` 2024-10-09 05:34:08 Just in case it still subscribes to MQTT and builds stuff, even though it is no longer listed on build.a.o 2024-10-09 05:39:27 it would just appear again 2024-10-09 05:39:47 Yeah, probably don't want that to happen 2024-10-09 06:06:21 cely:Yes, I have also executed rc-update del mqtt-exec.aports-build 2024-10-09 06:07:01 ikke:Thank you 2024-10-09 06:13:21 But I wonder why build-edge-tmp-loongarch64 has not been removed from build.alpinelinux.org, at least it is still there when I check the webpage 2024-10-09 06:14:38 Yeah, most likely that is it appearing again 2024-10-09 06:15:16 (will happen if aports-build runs, which it did just now, last aport it built was testing/perl-io-lambda, iirc) 2024-10-09 06:15:52 So, it will have to be removed from MQTT again, and hopefully with the OpenRC service disabled, it won't appear again 2024-10-09 09:50:04 clandmeter: I added loongarch64 key to lxc-templates-legacy !73284 2024-10-09 09:50:14 We can use "lxc-create -n edge-test -t alpine -- release=edge" to create an lxc container, but it seems that this can be done without loongarch64 key. 2024-10-09 18:16:20 anyone know if the banana pi 3a6000 SBC is actually available anywhere 2024-10-09 18:16:43 i’m looking to upgrade my home router and it seems like a perfect fit, if i could find it anywhere… 2024-10-10 03:10:33 Ariadne: I'm not sure about this, isn't it sold on aliexpress? 2024-10-10 03:11:59 only the loongson and asus boards are there 2024-10-10 03:15:37 lots of arm kit from banana pi but the loongson SKUs aren’t listed on their aliexpress store yet 2024-10-10 03:16:21 most of which are much slower than 3a6000 2024-10-10 03:21:29 the power consumption on 3a6000 SoC (IPC/watt let’s say) is really good 2024-10-10 03:38:02 Well, it may not be easy to get it in this case. I can ask if anyone knows where to find it. 2024-10-10 03:40:20 i think it’s not released yet 2024-10-10 03:40:31 is the issue 2024-10-10 05:56:56 Ariadne: I guess you also checked http://www.banana-pi.org.cn/en/buy, there are some purchase channels here 2024-10-10 05:57:04 I asked banana pi customer service, unfortunately there is no 3a6000 SBC at the moment, so it is not for sale 2024-10-10 19:27:14 huajingyun: yeah, the wiki page for the SKU seems to have only gone up on september 20, https://docs.banana-pi.org/en/BPI-3A6000/BananaPi_BPI-3A6000 so i guess it is still a product in development 2024-10-10 19:27:27 it is weird that they would publish product information about a product that isn't released yet though 2024-10-11 00:41:12 Ariadne: Yeah,still need to wait 2024-10-11 00:53:42 i think the product docs were published early to allow ODM partners to decide if they wanted to do anything with that product 2024-10-11 00:54:24 hopefully it is released soon, i have a lot of ideas. it seems like a solid platform to introduce loongarch commercially outside chinese market 2024-10-14 08:45:14 Ariadne:I heard that there are already some samples, hopefully it will be released soon so that you can get it sooner 2024-10-14 08:48:59 mps: Hi mps, can you switch the 4K kernel PAGE_SIZE of loongarch64 in linux-edge to 16k? We recommend to use 16k, otherwise it may cause poor performance or some functional problems. That's why it is still defaulted to 16k. 2024-10-14 08:49:12 Thank you! 2024-10-14 08:49:35 Maybe you asked this before, sorry I missed it 2024-10-14 09:07:45 huajingyun: Hi. I can but then I will 'lost' f2fs driver 2024-10-14 09:08:35 I had a hope that will be fixed with 6.12 kernel but looking git log looks like my hope is wrong 2024-10-14 09:09:31 not sure what do 2024-10-14 09:11:19 huajingyun: yes, I talked here about this issue when I built first kernel for loongarch64 2024-10-14 09:13:24 and I reported this problem (f2fs doesn't work with 16K page size) to upstream f2fs developers and they told me they will try to 'fix' but till now this is not yet happened 2024-10-14 09:15:09 mps:Can you send me a link? I'll see if I can move this forward. 2024-10-14 09:15:32 link? 2024-10-14 09:16:23 Yeah,link about reported this problem (f2fs doesn't work with 16K page size) 2024-10-14 09:17:48 ah, will try to find url of posts in f2fs mailing list (if it was not private mails) and post to you 2024-10-14 09:18:52 omg, they have ML but I communicated with them in private mail 2024-10-14 09:20:11 I could post thread to your mail later 2024-10-14 09:21:16 now I remember their ML required registration somewhere and because this used private mail 2024-10-14 09:21:49 ACTION hate to register on so much sites 2024-10-14 09:22:15 It's ok, I want to know if there is anyone from Loongson, that will make things easier 2024-10-14 09:22:21 even I don't have github account 2024-10-14 09:23:08 f2fs guys are mostly from south korea 2024-10-14 09:23:43 samsung related 2024-10-14 09:24:21 (now I need another cofffee) 2024-10-14 09:26:05 anyway, I will switch kernel to 16K on next upgrade and convert my FS to ext4. don't like idea that someone will tell that alpine on loongson is slow :) 2024-10-14 09:30:15 Thank you very much! 2024-10-14 09:30:26 In the future, we will also make the kernel upstream use 4k by default when the time is right. 2024-10-14 09:48:47 I found a link that seems f2fs supports 16k 2024-10-14 09:48:50 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d7e9a9037de27b642d5a3edef7c69e2a2b460287 2024-10-14 09:51:41 mps:Anyway, thanks for being willing to switch to 16k on the next upgrade:-D 2024-10-14 09:52:36 huajingyun: doesn't works well, you can make FS but it can't be mounted 2024-10-14 09:53:12 I tested it 2024-10-14 09:55:14 Oh, ok, it still isn't completely reliable, it seems. 2024-10-14 09:57:54 right 2024-10-14 10:56:09 huajingyun: forwarded f2fs private mail thread to you 2024-10-15 02:04:14 mps:Thanks, but I just checked and I didn't receive the email you sent. 2024-10-15 06:47:37 huajingyun: yes, I received mail from my mail server 'TLS is required, but was not offered by host mailgw.loongson.cn' 2024-10-15 06:48:31 have to see how to 'fix' this on my mail server (though I thought I fixed it long ago) 2024-10-15 06:51:07 mps: It's okay, no hurry 2024-10-15 06:52:49 hehe, I'm never in a hurry, even in war :) 2024-10-15 06:59:34 ncopa: I think we should upgrade linux-headers to 6.12 because next linux-lts very probably will be this version 2024-10-15 06:59:55 er... 2024-10-15 07:00:22 i am almost done with the aports bootstrap 2024-10-15 07:00:44 this is one of the things we should have done before we started bootsrapping aports 2024-10-15 07:01:10 hm, so linux-headers will be 6.6 for 3.21-stable? 2024-10-15 07:01:19 seems so yes 2024-10-15 07:01:32 not good 2024-10-15 07:01:41 what is the problem? 2024-10-15 07:02:34 if you remember we discussed this few times in previous years, so I think we shouldn't repeat again 2024-10-15 07:03:02 i still don't get why it is a problem. the linux ABI is stable 2024-10-15 07:03:22 new things in new kernels 2024-10-15 07:03:48 in new headers ABI is also stable 2024-10-15 07:03:54 and you think the apps will not utilize those unless new headers exists? 2024-10-15 07:04:21 some rare apps sometimes need new things 2024-10-15 07:04:38 do you have any examples of programs that will not use the new linux features when thye only have access to older headers? 2024-10-15 07:04:54 what I have seen apps do in that case is 2024-10-15 07:05:11 problem didn't manifests when we had small number of packages but nowadays I expect some 2024-10-15 07:05:13 #ifndef NEW_LINUX_CONSTANT 2024-10-15 07:05:28 #define NEW_LINUX_CONSTANT ... 2024-10-15 07:05:28 #endif 2024-10-15 07:06:01 yes, and all upstream will do this? 2024-10-15 07:06:12 if packages *needs* the new features, and will fail to build with old headers, then we will discover those 2024-10-15 07:06:20 that is what usually happens 2024-10-15 07:06:24 right 2024-10-15 07:06:40 so it is not a problem really 2024-10-15 07:07:24 and userspace (libs/apps) usually don't want to fail hard when running on older kernel, so even if they use new features, they alsmost always have a fallback 2024-10-15 07:07:49 but I have never seen that this depends on the version of linux headers 2024-10-15 07:08:02 also new headers don't make problems 2024-10-15 07:08:21 what i do have seen is new linux headers breaking builds 2024-10-15 07:08:33 due to they expect glibc 2024-10-15 07:08:37 at least in the past 2024-10-15 07:08:54 ah, didn't know 2024-10-15 07:09:09 so i wouldnt mind bumping the linux headers, but we should have done so before starting buildign any packages 2024-10-15 07:09:18 I never meet problem with new headers 2024-10-15 07:09:21 so we dont get bitten of it by surprise 2024-10-15 07:09:22 i have 2024-10-15 07:09:26 more than once 2024-10-15 07:09:58 ok 2024-10-15 07:10:14 Just wondering, which packages have been built? Those that are listed in bootstrap.sh? 2024-10-15 07:10:46 there are even a couple of patches in linux-headers dir as evidence 2024-10-15 07:12:43 cely: built everythign in dependecy chain for build-base and I am now working on a perl breakage 2024-10-15 07:13:10 What happened to Perl? 2024-10-15 07:13:11 that is riscv64 is still a bit behind 2024-10-15 07:13:29 >>> perl-extutils-cchecker: Analyzing dependencies... 2024-10-15 07:13:29 masked in: cache 2024-10-15 07:13:29 satisfies: world[.makedepends-perl-extutils-cchecker=20241014.211514] 2024-10-15 07:13:29 .makedepends-perl-extutils-cchecker-20241014.211514: 2024-10-15 07:13:29 ERROR: unable to select packages: 2024-10-15 07:13:29 required by: .makedepends-perl-extutils-cchecker-20241014.211514[perl-test2-suite] 2024-10-15 07:13:29 perl-test2-suite (no such package): 2024-10-15 07:13:31 >>> ERROR: perl-extutils-cchecker: builddeps failed 2024-10-15 07:13:46 smells like a circular dep 2024-10-15 07:14:24 74e36977a59354eeb1d4099b732a918dbee00a86 2024-10-15 07:14:25 Ah 2024-10-15 07:14:32 just found it :) 2024-10-15 07:14:44 Actually, perl-test2-suite is now in Perl core itself 2024-10-15 07:14:53 So you can just remove it, if it still builds 2024-10-15 07:14:53 cely if you have time to have a look at it? i need make breakfast 2024-10-15 07:15:18 Sure 2024-10-15 07:15:23 thanks! 2024-10-15 07:15:44 ncopa: Oh, have you finished the v3.21 aports bootstrap? 2024-10-15 07:15:49 I just tried to backport an upstream kernel patch, not sure if it's too late now 2024-10-15 07:15:55 About change SHMLBA from SZ_64K to PAGE_SIZE 2024-10-15 07:15:57 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/loongarch?h=v6.8&id=d23b77953f5a4fbf94c05157b186aac2a247ae32 2024-10-15 07:16:49 its not too late for kernel changes 2024-10-15 07:17:42 only foor significant changes in toolchains, gcc, make, cmake, bison, flex, binutils, etc. the tools that are used to build stuff 2024-10-15 07:18:09 When .NET was tested on alpine, it was found that this patch was needed. 2024-10-15 07:18:13 OK, then I will create a MR as soon as possible. 2024-10-15 07:18:19 it is in the kernel runtime? 2024-10-15 07:19:16 i dont think that changes in runtimes are a hurry yet, only buildtime changes, where the change would affect many other packages 2024-10-15 07:19:20 buildtime 2024-10-15 07:20:57 mps: if the headers are important to you, I could always only rebuild the packages using the headers 2024-10-15 07:21:25 but you would need to be there and help to solve any breakages if they unexpectedly break stuff 2024-10-15 07:21:48 it would set us back 1 day tops if we are efficient 2024-10-15 07:22:19 So, the dependency chain goes abuild -> fakeroot -> po4a -> perl-syntax-keyword-try -> perl-xs-parse-keyword -> perl-extutils-cchecker -> perl-test2-suite (perl-test-simple) 2024-10-15 07:23:11 Why's that a circular dep? 2024-10-15 07:23:50 perl-test-simple only depends on perl 2024-10-15 07:23:56 and perl only on bzip2 and zlib 2024-10-15 07:24:57 its not a circular dep. my guess was wrong. the problem is 74e36977a59354eeb1d4099b732a918dbee00a86 2024-10-15 07:25:01 package was removed 2024-10-15 07:25:23 but i added a provides="perl-test2-suite" 2024-10-15 07:25:35 oh 2024-10-15 07:25:38 `provides="perl-test2-suite=$pkgver-r$pkgrel"`* 2024-10-15 07:26:07 then it smells like a bug in lua-aports 2024-10-15 07:27:28 It is supposed to work... https://gitlab.alpinelinux.org/alpine/lua-aports/-/blob/master/spec/db_spec.lua?ref_type=heads#L256 2024-10-15 07:28:16 it failed to detect that it should build perl-test-simple before perl-extutils-cchecker 2024-10-15 07:28:35 it is probably related to the provides 2024-10-15 07:30:01 we should add a test for versioned depends 2024-10-15 07:30:14 sorry, versioned provides 2024-10-15 07:30:21 now i really need to get and get some coffe 2024-10-15 07:30:31 lua-aports couldn't detect the versioned provides? 2024-10-15 07:32:32 We did notice something in !69454 2024-10-15 07:36:25 That MR was merged a few days after !69357 2024-10-15 07:38:31 ncopa: I don't insist, just told my opinion. 2024-10-15 07:39:20 and ofc I will help wherever I can if I have free time and knowledge, unrelated to linux-headers 2024-10-15 07:40:51 if you plan to make 3.21 early then we will not have linux-lts 6.12 and headers upgrade is not important 2024-10-15 07:42:05 That will probably depend on how many new things have broken since the Loongarch builder built a complete main/ and community/ 2024-10-15 07:42:45 With a few abuild warnings now becoming errors, i don't think that number will be few 2024-10-15 07:46:09 ncopa: OK, I just created !73522. If you think it's not urgent, we can check it after 3.21 is released. I'll record it first to prevent missing it. 2024-10-15 07:49:27 In other news, Firefox on Loongarch is now built with Clang 19, which means vector instructions are enabled 2024-10-15 07:54:09 and it seems for Firefox 132, Mozilla finally upgraded the Rust libc crate to 0.2.158, so one patch less needed for Loongarch 2024-10-15 07:56:09 huajingyun: mail should be in your mailbox 2024-10-15 07:57:15 OK, let me check 2024-10-15 07:58:11 mps:Yes, got it, thank you 2024-10-15 07:58:22 huajingyun: np 2024-10-15 08:24:29 I'll be going AFK, bye 2024-10-15 08:33:56 Bye 2024-10-15 10:30:26 oh, i know now why perl thingy fails 2024-10-15 10:32:03 nothing pulls in perl-test-simple in the "need to be built list" and indirect provides are excluded from that list 2024-10-15 10:32:46 this is sort of complicated 2024-10-15 14:02:08 Ah, build-3-21-riscv64 is up 2024-10-15 14:02:32 and now build-3-21-loongarch64 is up 2024-10-15 14:06:11 It seems the builders were brought up with 230-252 aports in main/ already built, is that how many aports bootstrap.sh builds? 2024-10-15 14:21:12 No, it’s the packages for /etc/apk/world 2024-10-15 14:21:46 basically, build base, abuild and openssh 2024-10-15 14:22:01 and aports-build 2024-10-15 14:22:10 Ok 2024-10-15 14:22:52 So, is bootstrap.sh used to bootstrap the builders, or is there some other script? 2024-10-15 14:23:38 No. bootstrap.sh is to bootstrap a new architecture. 2024-10-15 14:23:43 Ok 2024-10-15 14:24:23 for builders I usually start with edge, delete every apk and build from scratch 2024-10-15 14:24:44 and I start with the packages needed by the builder itself 2024-10-15 14:24:45 That's interesting 2024-10-15 14:25:38 so everything needed by build-base, abuild and aports-build 2024-10-15 14:26:08 it is basically a world rebuild 2024-10-15 14:26:30 so everything is built with the latest gcc, abuild etc 2024-10-15 14:27:29 So, there is no set point in the build when the builders get onto MQTT? (as in, when they appear on build.a.o, the build process for main/ is already running) 2024-10-15 14:46:49 That happens when the mqtt-exec service is started 2024-10-15 14:47:41 Which executes aports-build, which then starts announcing to mqtt 2024-10-15 14:48:59 Ok 2024-10-15 14:49:36 Can aports-build be already running when mqtt-exec starts? 2024-10-15 14:50:53 It's rarely run by hand 2024-10-15 14:50:58 Except for debugging 2024-10-15 14:54:12 Ok, so i guess before aports-build takes over the process there is something else that builds the initial build-base/abuild/aports-build 2024-10-15 15:06:23 yes. i do the initial build-base 2024-10-15 15:06:57 #!/bin/sh 2024-10-15 15:06:57 : ${pkgs:=build-base} 2024-10-15 15:06:57 ap recursdeps $pkgs | xargs ap builddirs | while read aport; do 2024-10-15 15:06:57 pkgs="$@" 2024-10-15 15:06:57 cd ~/aports/main 2024-10-15 15:06:59 done 2024-10-15 15:06:59 (cd $aport && abuild -rk) || break 2024-10-15 15:07:07 thats how I do it 2024-10-15 15:07:18 and I set APORTS_BOOTSTRAP=1 2024-10-15 15:07:45 otherwhie half the world would be built 2024-10-15 15:08:26 Thanks 2024-10-15 15:08:37 git -C ~/aports pull --rebase && APORTS_BOOTSTRAP=1 sh ~/.abuild/bootstrap-aports.sh $(cat /etc/apk/world) 2024-10-15 15:08:59 thats how I run it 2024-10-15 15:09:28 actually, first I run it without the $(cat /etc/apk/world) 2024-10-15 15:09:50 second step i build the rest of installed world 2024-10-15 15:10:06 then I enable mqtt-exec.aports-build service 2024-10-15 15:10:10 and reboot the builder 2024-10-15 15:10:22 i have also checked that /tmp is mounted as tmpfs 2024-10-15 15:10:46 and i had to add .config/mosquitto_pub with the credentials to publish messages 2024-10-15 15:11:42 and i check that there is enough disk space 2024-10-15 15:11:49 which is becoming a problem 2024-10-15 15:14:51 now i only have arm builders left 2024-10-15 15:16:00 Ok 2024-10-15 15:31:45 they are all up now 2024-10-15 15:35:27 Alright, already fixed the first build issue due to ctest now erroring out if tests are not found (#16519) 2024-10-15 15:35:52 There will probably be more of that, hopefully not too many 2024-10-15 15:38:10 thank you! 2024-10-15 15:38:28 You're welcome 2024-10-15 15:38:41 i think there will not be many build failures. we did the big part when building for loongarch64 2024-10-15 15:38:57 so i think it will be relatively smooth 2024-10-15 15:39:03 Hopefully others also watching #alpine-commits can also make MR for the fixes 2024-10-15 15:39:03 disk space is a problem though 2024-10-15 15:39:08 yeah 2024-10-15 15:39:26 Now we also have https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10158 2024-10-15 15:39:58 I encountered that while trying to rebuild community/imhex against llvm 19 (also abuild 3.14) 2024-10-15 15:40:46 imhex is not flutter, and it was failing to trace one of the imhex plugins (which is already in the imhex package), so i just fixed it with somask 2024-10-15 15:42:34 also the reason why !73478 has started failing (issue was there all along), though in this case it's probably precompiled assets linked against glibc as noted in the comment 2024-10-15 15:43:39 Flutter is still in testing/, so probably all other aports encountering this issue in the 3.21 rebuild are due to something else 2024-10-15 15:49:55 So these are the two changes to abuild that will probably cause some failures that were not present while bringing up build-edge-loongarch64: ctest failing if no tests are run, and trace deps failing if abuild can't find the soname path 2024-10-15 15:57:42 Ok, the trace deps issue was just noted in https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/70101#note_445713 (abseil-cpp upgrade) 2024-10-15 15:58:41 Seems like it may affect OpenJDK as well 2024-10-15 16:12:42 Commented on !70101 with the abuild commits i think are related to the 2 changes that will cause new failures 2024-10-15 16:20:00 nod 2024-10-15 16:20:26 I may have determined the commits wrongly (still not really sure about the trace deps one), so corrections welcome 2024-10-15 17:11:22 I'll be going AFK, bye 2024-10-16 03:59:18 not sure if anyone here would like to look into this, main/libssh2 has 2 failed tests on loongarch64. build passed on x86_64 and aarch64 https://build.alpinelinux.org/buildlogs/build-3-21-loongarch64/main/libssh2/libssh2-1.11.0-r3.log 2024-10-16 04:10:07 It seems there are almost 200 aports in community/ affected by the ctest and soname issues 2024-10-16 04:10:09 This is not looking good 2024-10-16 04:10:41 So, please do not turn anymore abuild warnings into errors for Alpine 3.21 2024-10-16 04:11:24 any more* 2024-10-16 04:24:06 I think the total count is 198 aports affected, 195 in community/ and 3 in main/ 2024-10-16 06:19:37 I can't figure out why libssh2 fails on the 3.21 builder. I built it manually locally and it passed 2024-10-16 06:22:10