2024-10-01 01:47:19 <qaqland> huajingyun: fix in !72792
2024-10-01 01:49:04 <cely> It's been merged
2024-10-01 01:49:27 <cely> Thanks to J0WI
2024-10-01 04:40:04 <ikke> 7 packages remaining
2024-10-01 04:42:02 <cely> Most with open MRs
2024-10-01 04:42:05 <mio> 6 ... "why is it always xsane" :)
2024-10-01 04:42:12 <mio> so haven't cycled the builder
2024-10-01 04:45:15 <mio> 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 <mio> 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 <mio> the other 4 as cely said have MRs pending
2024-10-01 04:48:31 <mio> apt-dater cri-o libretro-daphne xsane
2024-10-01 22:21:22 <mio> last one needed to unblock testing/ is in the MR queue
2024-10-02 11:50:09 <ncopa> the build-edge-loongarch64 is done! \o/
2024-10-02 12:16:27 <ikke> \o/
2024-10-02 12:17:37 <mps> now can change /etc/apk/repositorirs to CDN
2024-10-02 12:37:10 <ncopa> and we can decomission the 	build-edge-tmp-loongarch64
2024-10-02 13:51:28 <mio> \o/
2024-10-02 16:02:03 <cely> Would now be the time to remove `allow_failure: true` for the Loongarch CI?
2024-10-02 16:02:19 <ikke> probably yes
2024-10-02 17:03:17 <cely> New fortify-headers broke Rust again: https://gitlab.alpinelinux.org/Celeste/aports/-/jobs/1541687
2024-10-02 17:05:18 <cely> As usual, ppc64le seems unaffected, and this time, s390x also seems unaffected
2024-10-02 17:05:40 <cely> I have a very strong suspicion that fortify-headers isn't being applied at all to ppc64le
2024-10-02 17:24:06 <cely> but that's for tomorrow
2024-10-02 17:24:10 <cely> Going AFK now, bye
2024-10-02 17:27:38 <ikke> o/
2024-10-02 17:40:54 <ncopa> which is the PR for that job?
2024-10-02 17:42:49 <celie> 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 <ncopa> i pushed update to fortify-headers
2024-10-02 17:43:17 <ikke> celie: how is the pipeline triggered? For aports we only have pipelines for MRs
2024-10-02 17:43:39 <celie> Through glab
2024-10-02 17:44:46 <celie> 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 <ikke> ok
2024-10-02 17:45:30 <ikke> Curious how that works, because everything assumes there is an MR
2024-10-02 17:45:40 <celie> 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 <celie> 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 <celie> Ok, AFK for real now, bye
2024-10-02 17:48:50 <ikke> aha, ok, so you then provide something like CI_MERGE_REQUEST_TARGET_BRANCH_NAME manually
2024-10-02 18:29:50 <clandmeter> ncopa: i guess you could add edge to releases.json?
2024-10-02 18:30:11 <ncopa> i guess i could
2024-10-02 18:30:22 <ikke> reason is that the new pkgs.a.o looks at that
2024-10-02 18:30:29 <clandmeter> pkgs should then auto update
2024-10-02 18:30:38 <clandmeter> i hope :)
2024-10-02 18:36:27 <ncopa> pushed new alpine-releases.conf.yaml
2024-10-02 18:38:22 <clandmeter> thx, lets see in a couple of minutes
2024-10-02 18:38:36 <clandmeter> well it will take a bit longer to process all pkgs
2024-10-02 18:48:34 <clandmeter> yup, loongarch is popping up on pkgs.a.o
2024-10-02 18:48:39 <ikke> nice
2024-10-02 18:49:14 <clandmeter> now i just hope it finished without errors
2024-10-02 18:49:23 <clandmeter> cause the logic is not perfect for larger updates
2024-10-02 18:49:33 <clandmeter> but similar to previous
2024-10-02 18:50:38 <clandmeter> 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 <ikke> ok, good to kn ow
2024-10-02 18:51:27 <clandmeter> 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 <clandmeter> oh this is not infra channel.
2024-10-03 01:08:07 <celie> 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 <cely> 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 <cely> It would be nice to have !72509 in Alpine 3.21
2024-10-04 13:56:12 <mps> +1
2024-10-04 13:56:29 <ncopa> cely: feel free to set milestones for things we should try get included in 3.21
2024-10-04 13:59:42 <cely> Ok
2024-10-07 03:23:14 <Ariadne> are there any plans to implement STRICT_KERNEL_RWX on loongarch?
2024-10-07 03:25:29 <Ariadne> looking at the risc-v implementation it shouldn't be too difficult to accomplish
2024-10-07 21:12:45 <ncopa> lld 19.1.1 seems to be broken on loongarch64: https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1548406
2024-10-08 00:46:24 <celie> Could it be because scudo-malloc 18 is used?
2024-10-08 00:47:59 <celie> I tried LLVM 19 release candidates, but can't remember how far i went (if i tried lld19)
2024-10-08 00:48:21 <celie> I'll try to check my work in a moment
2024-10-08 01:11:13 <cely> Hmm, that was a month ago, and i can't remember what i was doing now :(
2024-10-08 01:13:24 <cely> Hmm, it seems checks fail, so i didn't manage to get them to pass
2024-10-08 01:14:34 <huajingyun> Good morning, I'm back from vacation.
2024-10-08 01:14:42 <huajingyun> 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 <huajingyun> qaqland: Thanks for fixing git-interactive-rebase-tool
2024-10-08 01:17:32 <huajingyun>  cely:Did you pass lld19 before because you disabled the check for it?
2024-10-08 01:18:36 <cely> No, it didn't pass
2024-10-08 01:18:45 <cely> Checks fail, even with scudo-malloc 19
2024-10-08 01:20:46 <Ariadne> those tests are failing with exit code 132
2024-10-08 01:20:53 <Ariadne> subtract 128
2024-10-08 01:21:22 <Ariadne> SIGILL
2024-10-08 01:21:35 <Ariadne> so... could be alignment, could be vectors, could be FORTIFY
2024-10-08 01:22:42 <Ariadne> FORTIFY i think is SIGTRAP on loongarch
2024-10-08 01:22:45 <Ariadne> let me verify
2024-10-08 01:23:17 <Ariadne> yes, SIGTRAP
2024-10-08 01:23:25 <Ariadne> so, that leaves alignment and vectors
2024-10-08 01:30:21 <Ariadne> 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 <Ariadne> (userspace W^X is already covered in openpax kernel patch)
2024-10-08 01:38:56 <cely> Maybe it is vectors, what have we done regarding this so far?
2024-10-08 01:40:18 <cely> I know a patch for musl was added, but what else needs to be done?
2024-10-08 02:01:40 <cely> 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 <huajingyun> 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 <Ariadne> huajingyun: i'm happy to help with it
2024-10-08 02:48:43 <Ariadne> though at the moment i am getting ready to port coreboot
2024-10-08 02:49:02 <Ariadne> (my goal is to replace the loongson firmware with fully open source one)
2024-10-08 02:53:10 <Ariadne> coreboot + loongarch = reasonably priced entirely libre compute option
2024-10-08 02:53:56 <cely> 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 <cely> Well, it's just the firmware binaries
2024-10-08 02:58:06 <cely> Anyway, lld tests may be solved by upgrading CI runners to a kernel with LSX/LASX enabled
2024-10-08 02:59:48 <cely> !70603 was the MR that enabled it
2024-10-08 02:59:59 <Ariadne> yeah i think it's the issue
2024-10-08 03:00:32 <huajingyun> Ariadne:That would be great, we would really appreciate your help with this
2024-10-08 03:01:46 <huajingyun> CI needs to upgrade the kernel, and tmp-builder also needs
2024-10-08 03:02:38 <Ariadne> tmp-builder should be decommissioned and reallocated as a porterbox or similar imo
2024-10-08 03:03:05 <Ariadne> the official builder has fully rebuilt the distro
2024-10-08 03:14:33 <huajingyun> Yes, it is indeed not necessary to repeatedly build aports in tmp-builder
2024-10-08 03:14:44 <huajingyun> 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 <huajingyun> 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 <Ariadne> yeah that is what i mean by porterbox :)
2024-10-08 03:25:30 <Ariadne> a machine that developers without a loongarch machine can use
2024-10-08 03:25:54 <Ariadne> though, it's fairly easy to buy loongarch machines now with aliexpress and others
2024-10-08 04:07:23 <ikke> Ariadne: we already have a dev server for loongarch64 
2024-10-08 07:53:38 <ncopa> morning! welcome back huajingyun! hope you had a good vacation
2024-10-08 07:53:50 <ncopa> cely: thanks for the scudo-malloc pointer. will fix that
2024-10-08 07:59:22 <huajingyun> ncopa:Thank you,i may upgrade the kernel for tmp-builder later to enable LSX/LASX
2024-10-08 08:46:36 <ncopa> I think we can decommision tmp-builder
2024-10-08 08:51:06 <ncopa> build-edge-loongarch64 runs 6.6.47-0-lts
2024-10-08 09:04:33 <cely> Are we planning to make llvm19 the default LLVM for Alpine 3.21?
2024-10-08 09:08:14 <ncopa> that is what I am hoping for yes
2024-10-08 09:08:24 <ncopa> that is what I am working on currently
2024-10-08 09:08:46 <cely> 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 <huajingyun> 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 <ncopa> ah, will try to find the ci machine and upgrade that. asap
2024-10-08 09:10:03 <cely> Rust 1.82.0 will be released on the 17th
2024-10-08 09:10:24 <cely> but a pre-release is usually available the Monday before (14th)
2024-10-08 09:12:21 <cely> 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 <cely> Anyway, this will probably have some consequences for Firefox too
2024-10-08 09:16:25 <cely> 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 <ncopa> lets discuss that in #alpine-devel
2024-10-08 09:17:06 <cely> or in #alpine-rust
2024-10-08 09:21:35 <huajingyun> ncopa:Thanks
2024-10-08 09:21:57 <huajingyun> 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 <huajingyun> 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 <huajingyun> 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 <ncopa> So I just power it off, and thats it?
2024-10-08 09:27:10 <huajingyun> ncopa:I think for now it might just be necessary to remove in build.alpinelinux.org
2024-10-08 09:35:03 <ncopa> ok
2024-10-08 09:40:45 <huajingyun> Thanks
2024-10-08 18:46:45 <Ariadne> 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 <ikke> FYI, both CI hosts are running 6.6.54-0-lts now
2024-10-09 00:58:39 <huajingyun>  ikke: Thanks
2024-10-09 01:28:53 <celie> 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 <cely> 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 <huajingyun> 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 <ikke> 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 <huajingyun> 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 <huajingyun> Is there anything else we need to do?
2024-10-09 05:07:34 <ikke> There is no explicit support to remove a builder, it needs to be done manually
2024-10-09 05:09:58 <ikke> I removed it from mosquitto now
2024-10-09 05:16:08 <ikke> restarted builder-server-status, the builder is now no longer mentioned
2024-10-09 05:32:28 <cely> Maybe you should do `rc-update del mqtt-exec.aports-build`
2024-10-09 05:34:08 <cely> 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 <ikke> it would just appear again
2024-10-09 05:39:47 <cely> Yeah, probably don't want that to happen
2024-10-09 06:06:21 <huajingyun> cely:Yes, I have also executed rc-update del mqtt-exec.aports-build
2024-10-09 06:07:01 <huajingyun> ikke:Thank you 
2024-10-09 06:13:21 <huajingyun> 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 <cely> Yeah, most likely that is it appearing again
2024-10-09 06:15:16 <cely> (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 <cely> 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 <huajingyun> clandmeter:  I added loongarch64 key to lxc-templates-legacy !73284
2024-10-09 09:50:14 <huajingyun> 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 <Ariadne> anyone know if the banana pi 3a6000 SBC is actually available anywhere
2024-10-09 18:16:43 <Ariadne> 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 <huajingyun> Ariadne: I'm not sure about this, isn't it sold on aliexpress?
2024-10-10 03:11:59 <Ariadne> only the loongson and asus boards are there
2024-10-10 03:15:37 <Ariadne> 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 <Ariadne> most of which are much slower than 3a6000
2024-10-10 03:21:29 <Ariadne> the power consumption on 3a6000 SoC (IPC/watt let’s say) is really good
2024-10-10 03:38:02 <huajingyun> 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 <Ariadne> i think it’s not released yet
2024-10-10 03:40:31 <Ariadne> is the issue
2024-10-10 05:56:56 <huajingyun> 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 <huajingyun> 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 <Ariadne> 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 <Ariadne> it is weird that they would publish product information about a product that isn't released yet though
2024-10-11 00:41:12 <huajingyun>  Ariadne: Yeah,still need to wait
2024-10-11 00:53:42 <Ariadne> 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 <Ariadne> 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 <huajingyun> 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 <huajingyun> 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 <huajingyun> Thank you!
2024-10-14 08:49:35 <huajingyun> Maybe you asked this before, sorry I missed it
2024-10-14 09:07:45 <mps> huajingyun: Hi. I can but then I will 'lost' f2fs driver
2024-10-14 09:08:35 <mps> 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 <mps> not sure what do
2024-10-14 09:11:19 <mps> huajingyun: yes, I talked here about this issue when I built first kernel for loongarch64
2024-10-14 09:13:24 <mps> 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 <huajingyun> mps:Can you send me a link? I'll see if I can move this forward.
2024-10-14 09:15:32 <mps> link?
2024-10-14 09:16:23 <huajingyun> Yeah,link about reported this problem (f2fs doesn't work with 16K page size)
2024-10-14 09:17:48 <mps> 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 <mps> omg, they have ML but I communicated with them in private mail
2024-10-14 09:20:11 <mps> I could post thread to your mail later
2024-10-14 09:21:16 <mps> now I remember their ML required registration somewhere and because this used private mail
2024-10-14 09:21:49 <mps> 
ACTION hate to register on so much sites

2024-10-14 09:22:15 <huajingyun> It's ok, I want to know if there is anyone from Loongson, that will make things easier
2024-10-14 09:22:21 <mps> even I don't have github account
2024-10-14 09:23:08 <mps> f2fs guys are mostly from south korea
2024-10-14 09:23:43 <mps> samsung related
2024-10-14 09:24:21 <mps> (now I need another cofffee)
2024-10-14 09:26:05 <mps> 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 <huajingyun> Thank you very much! 
2024-10-14 09:30:26 <huajingyun> 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 <huajingyun> I found a link that seems f2fs supports 16k
2024-10-14 09:48:50 <huajingyun> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d7e9a9037de27b642d5a3edef7c69e2a2b460287
2024-10-14 09:51:41 <huajingyun> mps:Anyway, thanks for being willing to switch to 16k on the next upgrade:-D
2024-10-14 09:52:36 <mps> huajingyun: doesn't works well, you can make FS but it can't be mounted
2024-10-14 09:53:12 <mps> I tested it
2024-10-14 09:55:14 <huajingyun> Oh, ok, it still isn't completely reliable, it seems.
2024-10-14 09:57:54 <mps> right
2024-10-14 10:56:09 <mps> huajingyun: forwarded f2fs private mail thread to you
2024-10-15 02:04:14 <huajingyun> mps:Thanks, but I just checked and I didn't receive the email you sent.
2024-10-15 06:47:37 <mps> 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 <mps> 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 <huajingyun> mps: It's okay, no hurry
2024-10-15 06:52:49 <mps> hehe, I'm never in a hurry, even in war :)
2024-10-15 06:59:34 <mps> 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 <ncopa> er...
2024-10-15 07:00:22 <ncopa> i am almost done with the aports bootstrap
2024-10-15 07:00:44 <ncopa> this is one of the things we should have done before we started bootsrapping aports
2024-10-15 07:01:10 <mps> hm, so linux-headers will be 6.6 for 3.21-stable?
2024-10-15 07:01:19 <ncopa> seems so yes
2024-10-15 07:01:32 <mps> not good
2024-10-15 07:01:41 <ncopa> what is the problem?
2024-10-15 07:02:34 <mps> 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 <ncopa> i still don't get why it is a problem. the linux ABI is stable
2024-10-15 07:03:22 <mps> new things in new kernels
2024-10-15 07:03:48 <mps> in new headers ABI is also stable
2024-10-15 07:03:54 <ncopa> and you think the apps will not utilize those unless new headers exists?
2024-10-15 07:04:21 <mps> some rare apps sometimes need new things
2024-10-15 07:04:38 <ncopa> 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 <ncopa> what I have seen apps do in that case is
2024-10-15 07:05:11 <mps> problem didn't manifests when we had small number of packages but nowadays I expect some
2024-10-15 07:05:13 <ncopa> #ifndef NEW_LINUX_CONSTANT
2024-10-15 07:05:28 <ncopa> #define NEW_LINUX_CONSTANT ...
2024-10-15 07:05:28 <ncopa> #endif
2024-10-15 07:06:01 <mps> yes, and all upstream will do this?
2024-10-15 07:06:12 <ncopa> 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 <ncopa> that is what usually happens
2024-10-15 07:06:24 <mps> right
2024-10-15 07:06:40 <ncopa> so it is not a problem really
2024-10-15 07:07:24 <ncopa> 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 <ncopa> but I have never seen that this depends on the version of linux headers
2024-10-15 07:08:02 <mps> also new headers don't make problems
2024-10-15 07:08:21 <ncopa> what i do have seen is new linux headers breaking builds
2024-10-15 07:08:33 <ncopa> due to they expect glibc
2024-10-15 07:08:37 <ncopa> at least in the past
2024-10-15 07:08:54 <mps> ah, didn't know
2024-10-15 07:09:09 <ncopa> 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 <mps> I never meet problem with new headers
2024-10-15 07:09:21 <ncopa> so we dont get bitten of it by surprise
2024-10-15 07:09:22 <ncopa> i have
2024-10-15 07:09:26 <ncopa> more than once
2024-10-15 07:09:58 <mps> ok
2024-10-15 07:10:14 <cely> Just wondering, which packages have been built? Those that are listed in bootstrap.sh?
2024-10-15 07:10:46 <ncopa> there are even a couple of patches in linux-headers dir as evidence
2024-10-15 07:12:43 <ncopa> cely: built everythign in dependecy chain for build-base and I am now working on a perl breakage
2024-10-15 07:13:10 <cely> What happened to Perl?
2024-10-15 07:13:11 <ncopa> that is riscv64 is still a bit behind
2024-10-15 07:13:29 <ncopa> >>> perl-extutils-cchecker: Analyzing dependencies...
2024-10-15 07:13:29 <ncopa>     masked in: cache
2024-10-15 07:13:29 <ncopa>     satisfies: world[.makedepends-perl-extutils-cchecker=20241014.211514]
2024-10-15 07:13:29 <ncopa>   .makedepends-perl-extutils-cchecker-20241014.211514:
2024-10-15 07:13:29 <ncopa> ERROR: unable to select packages:
2024-10-15 07:13:29 <ncopa>     required by: .makedepends-perl-extutils-cchecker-20241014.211514[perl-test2-suite]
2024-10-15 07:13:29 <ncopa>   perl-test2-suite (no such package):
2024-10-15 07:13:31 <ncopa> >>> ERROR: perl-extutils-cchecker: builddeps failed
2024-10-15 07:13:46 <ncopa> smells like a circular dep
2024-10-15 07:14:24 <ncopa> 74e36977a59354eeb1d4099b732a918dbee00a86
2024-10-15 07:14:25 <cely> Ah
2024-10-15 07:14:32 <ncopa> just found it :)
2024-10-15 07:14:44 <cely> Actually, perl-test2-suite is now in Perl core itself
2024-10-15 07:14:53 <cely> So you can just remove it, if it still builds
2024-10-15 07:14:53 <ncopa> cely if you have time to have a look at it? i need make breakfast
2024-10-15 07:15:18 <cely> Sure
2024-10-15 07:15:23 <ncopa> thanks!
2024-10-15 07:15:44 <huajingyun> ncopa: Oh, have you finished the v3.21 aports bootstrap?
2024-10-15 07:15:49 <huajingyun> I just tried to backport an upstream kernel patch, not sure if it's too late now
2024-10-15 07:15:55 <huajingyun> About change SHMLBA from SZ_64K to PAGE_SIZE
2024-10-15 07:15:57 <huajingyun> 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 <ncopa> its not too late for kernel changes
2024-10-15 07:17:42 <ncopa> 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 <huajingyun> When .NET was tested on alpine, it was found that this patch was needed.
2024-10-15 07:18:13 <huajingyun> OK, then I will create a MR as soon as possible.
2024-10-15 07:18:19 <ncopa> it is in the kernel runtime?
2024-10-15 07:19:16 <ncopa> 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 <ncopa> buildtime
2024-10-15 07:20:57 <ncopa> mps: if the headers are important to you, I could always only rebuild the packages using the headers
2024-10-15 07:21:25 <ncopa> but you would need to be there and help to solve any breakages if they unexpectedly break stuff
2024-10-15 07:21:48 <ncopa> it would set us back 1 day tops if we are efficient
2024-10-15 07:22:19 <cely> 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 <cely> Why's that a circular dep?
2024-10-15 07:23:50 <cely> perl-test-simple only depends on perl
2024-10-15 07:23:56 <cely> and perl only on bzip2 and zlib
2024-10-15 07:24:57 <ncopa> its not a circular dep. my guess was wrong. the problem is 74e36977a59354eeb1d4099b732a918dbee00a86
2024-10-15 07:25:01 <ncopa> package was removed
2024-10-15 07:25:23 <cely> but i added a provides="perl-test2-suite"
2024-10-15 07:25:35 <ncopa> oh
2024-10-15 07:25:38 <cely> `provides="perl-test2-suite=$pkgver-r$pkgrel"`*
2024-10-15 07:26:07 <ncopa> then it smells like a bug in lua-aports
2024-10-15 07:27:28 <ncopa> 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 <ncopa> it failed to detect that it should build perl-test-simple before perl-extutils-cchecker
2024-10-15 07:28:35 <ncopa> it is probably related to the provides
2024-10-15 07:30:01 <ncopa> we should add a test for versioned depends
2024-10-15 07:30:14 <ncopa> sorry, versioned provides
2024-10-15 07:30:21 <ncopa> now i really need to get and get some coffe
2024-10-15 07:30:31 <cely> lua-aports couldn't detect the versioned provides?
2024-10-15 07:32:32 <cely> We did notice something in !69454
2024-10-15 07:36:25 <cely> That MR was merged a few days after !69357
2024-10-15 07:38:31 <mps> ncopa: I don't insist, just told my opinion.
2024-10-15 07:39:20 <mps> 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 <mps> 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 <cely> 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 <cely> With a few abuild warnings now becoming errors, i don't think that number will be few
2024-10-15 07:46:09 <huajingyun> 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 <cely> In other news, Firefox on Loongarch is now built with Clang 19, which means vector instructions are enabled
2024-10-15 07:54:09 <cely> 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 <mps> huajingyun: mail should be in your mailbox
2024-10-15 07:57:15 <huajingyun> OK, let me check
2024-10-15 07:58:11 <huajingyun> mps:Yes, got it, thank you
2024-10-15 07:58:22 <mps> huajingyun: np
2024-10-15 08:24:29 <cely> I'll be going AFK, bye
2024-10-15 08:33:56 <huajingyun> Bye
2024-10-15 10:30:26 <ncopa> oh, i know now why perl thingy fails
2024-10-15 10:32:03 <ncopa> 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 <ncopa> this is sort of complicated
2024-10-15 14:02:08 <cely> Ah, build-3-21-riscv64 is up
2024-10-15 14:02:32 <cely> and now build-3-21-loongarch64 is up
2024-10-15 14:06:11 <cely> 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 <ncopa> No, it’s the packages for /etc/apk/world
2024-10-15 14:21:46 <ncopa> basically, build base, abuild and openssh 
2024-10-15 14:22:01 <ncopa> and aports-build
2024-10-15 14:22:10 <cely> Ok
2024-10-15 14:22:52 <cely> So, is bootstrap.sh used to bootstrap the builders, or is there some other script?
2024-10-15 14:23:38 <ncopa> No. bootstrap.sh is to bootstrap a new architecture.
2024-10-15 14:23:43 <cely> Ok
2024-10-15 14:24:23 <ncopa> for builders I usually start with edge, delete every apk and build from scratch 
2024-10-15 14:24:44 <ncopa> and I start with the packages needed by the builder itself 
2024-10-15 14:24:45 <cely> That's interesting
2024-10-15 14:25:38 <ncopa> so everything needed by build-base, abuild and aports-build
2024-10-15 14:26:08 <ncopa> it is basically a world rebuild
2024-10-15 14:26:30 <ncopa> so everything is built with the latest gcc, abuild etc
2024-10-15 14:27:29 <cely> 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 <ikke> That happens when the mqtt-exec service is started 
2024-10-15 14:47:41 <ikke> Which executes aports-build, which then starts announcing to mqtt
2024-10-15 14:48:59 <cely> Ok
2024-10-15 14:49:36 <cely> Can aports-build be already running when mqtt-exec starts?
2024-10-15 14:50:53 <ikke> It's rarely run by hand
2024-10-15 14:50:58 <ikke> Except for debugging 
2024-10-15 14:54:12 <cely> 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 <ncopa> yes. i do the initial build-base
2024-10-15 15:06:57 <ncopa> #!/bin/sh
2024-10-15 15:06:57 <ncopa> : ${pkgs:=build-base}
2024-10-15 15:06:57 <ncopa> ap recursdeps $pkgs | xargs ap builddirs | while read aport; do
2024-10-15 15:06:57 <ncopa> pkgs="$@"
2024-10-15 15:06:57 <ncopa> cd ~/aports/main
2024-10-15 15:06:59 <ncopa> done
2024-10-15 15:06:59 <ncopa>         (cd $aport && abuild -rk) || break
2024-10-15 15:07:07 <ncopa> thats how I do it
2024-10-15 15:07:18 <ncopa> and I set APORTS_BOOTSTRAP=1
2024-10-15 15:07:45 <ncopa> otherwhie half the world would be built
2024-10-15 15:08:26 <cely> Thanks
2024-10-15 15:08:37 <ncopa> git -C ~/aports pull --rebase && APORTS_BOOTSTRAP=1 sh ~/.abuild/bootstrap-aports.sh $(cat /etc/apk/world)
2024-10-15 15:08:59 <ncopa> thats how I run it
2024-10-15 15:09:28 <ncopa> actually, first I run it without the $(cat /etc/apk/world)
2024-10-15 15:09:50 <ncopa> second step i build the rest of installed world
2024-10-15 15:10:06 <ncopa> then I enable mqtt-exec.aports-build service
2024-10-15 15:10:10 <ncopa> and reboot the builder
2024-10-15 15:10:22 <ncopa> i have also checked that /tmp is mounted as tmpfs
2024-10-15 15:10:46 <ncopa> and i had to add .config/mosquitto_pub with the credentials to publish messages
2024-10-15 15:11:42 <ncopa> and i check that there is enough disk space
2024-10-15 15:11:49 <ncopa> which is becoming a problem
2024-10-15 15:14:51 <ncopa> now i only have arm builders left
2024-10-15 15:16:00 <cely> Ok
2024-10-15 15:31:45 <ncopa> they are all up now
2024-10-15 15:35:27 <cely> 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 <cely> There will probably be more of that, hopefully not too many
2024-10-15 15:38:10 <ncopa> thank you!
2024-10-15 15:38:28 <cely> You're welcome
2024-10-15 15:38:41 <ncopa> i think there will not be many build failures. we did the big part when building for loongarch64
2024-10-15 15:38:57 <ncopa> so i think it will be relatively smooth
2024-10-15 15:39:03 <cely> Hopefully others also watching #alpine-commits can also make MR for the fixes
2024-10-15 15:39:03 <ncopa> disk space is a problem though
2024-10-15 15:39:08 <ncopa> yeah
2024-10-15 15:39:26 <cely> Now we also have https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10158
2024-10-15 15:39:58 <cely> I encountered that while trying to rebuild community/imhex against llvm 19 (also abuild 3.14)
2024-10-15 15:40:46 <cely> 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 <cely> 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 <cely> 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 <cely> 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 <cely> 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 <cely> Seems like it may affect OpenJDK as well
2024-10-15 16:12:42 <cely> 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 <ikke> nod
2024-10-15 16:20:26 <cely> 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 <cely> I'll be going AFK, bye