2024-03-02 06:10:52 <huajingyun> hi, I have recently submitted aports loongarch64 fix to my personal repository in gitlab. 
2024-03-02 06:10:52 <huajingyun> https://gitlab.alpinelinux.org/huajingyun01/aports/-/tree/master-la-dev?ref_type=heads
2024-03-02 06:10:52 <huajingyun> and here is based on aports upstream commit: 9c13e7eac967782d64cfb2c4ffea78322e1b7b06
2024-03-02 06:10:52 <huajingyun> In the past two weeks, we have also spent time building alpine and verifying the newly added fixes of musl loongarch64. These musl fixes have all been pushed to musl upstream and have been included in 1.2.5.
2024-03-02 06:10:52 <huajingyun> This is the current apks built based on musl 1.2.5 :  https://dev.alpinelinux.org/~loongarch/edge-9c13e7
2024-03-02 06:11:37 <huajingyun> Can you take the time to take a look?  
2024-03-02 06:11:42 <huajingyun> Thanks.
2024-03-02 06:13:42 <ikke> Comparisson against upstream master: https://gitlab.alpinelinux.org/huajingyun01/aports/-/compare/master...master-la-dev?from_project_id=1&straight=false
2024-03-02 06:27:12 <huajingyun> Thank you ikke. During this period, huajingyun01/aports has fallen behind edge by about 1440 commits. 
2024-03-02 06:27:19 <huajingyun> so some commit may have conflicts.
2024-03-02 06:28:23 <ikke> To upstream this, it would be good to split it up and create merge requests. Something relatively simple / acceptable would be the update_config_sub/guess changes
2024-03-02 06:29:42 <ikke> Those can be done in bulk (perhaps one MR per repo, main, community and testing)
2024-03-02 06:31:45 <huajingyun> ok, so I need to create MRs for these changes in batches, right?
2024-03-02 06:38:22 <huajingyun> In addition, the 3 build machines we planned have arrived, and our team colleagues are installing the alpine OS on them
2024-03-02 06:38:33 <huajingyun> I think we should be able to provide it to you next week.:)
2024-03-02 06:46:22 <ikke> huajingyun: it makes reviewing them easier. And packages are maintained by different people, so it gives them a chance to vet the changes as well
2024-03-02 06:50:42 <huajingyun> okay thank you, i will do it next
2024-03-02 06:58:20 <ikke> huajingyun: do you happen to know if docker itself supports loongarch64 images?
2024-03-02 06:58:36 <ikke> Like official images
2024-03-02 07:12:35 <huajingyun> docker itself already supports loongarch64 I mean docker can work on loongarch64
2024-03-02 07:12:35 <huajingyun> but official images rely on alpine as the base image. We very much hope that alpine can be the first released loongarch64 base image. This will be a great thing.
2024-03-02 07:13:10 <ikke> huajingyun: yes, but it's docker itself that is building the images
2024-03-02 07:13:16 <ikke> so if they don't have hw, they cannot build it
2024-03-02 07:13:28 <ikke> The official images I mean
2024-03-02 07:21:01 <ikke> huajingyun: ncop just makes a pull request against this file: https://github.com/docker-library/official-images/blob/master/library/alpine
2024-03-02 07:21:10 <ikke> then docker builds the image from that description
2024-03-02 07:29:59 <huajingyun> thank, I see. our docker team is working on it, and will provide build machines to docker official upstream.
2024-03-02 07:30:07 <huajingyun> This will become easier to move forward once alpine supports loongarch64
2024-03-02 07:33:25 <ikke> Right, so for CI, we will probably build a local copy of the base image and keep that on the host, that will make the rest easier
2024-03-02 07:45:41 <huajingyun> I already have a local alpine docker image.
2024-03-02 07:45:54 <ikke> ok
2024-03-02 07:52:57 <huajingyun> thanks
2024-03-02 08:50:10 <clandmeter> hi
2024-03-02 08:51:07 <clandmeter> huajingyun: please keep in mind that you probably do not have to pump pkgrel
2024-03-02 08:52:27 <clandmeter> we only bump pkgrel if the outcome of the package is different
2024-03-02 08:52:42 <clandmeter> but we do not have a repo to compare with
2024-03-02 08:53:16 <clandmeter> if the diff does affect other arches it would need a bump
2024-03-02 09:02:28 <clandmeter> creating patch sets MRs is the best way, this will make it easier to get this into aports. If the logic of one patch is similar to the rest please bundle them. this way we do not have to review each patch but scan if its done correctly. more complex changes please create individual MR's.
2024-03-02 09:10:09 <huajingyun> hi,clandmeter,thanks for the reminder
2024-03-02 09:10:22 <huajingyun> so no need to pkgrel +1 when modifying any package, whether it is update_config_sub/guess or arch-related modifications，right?
2024-03-02 09:10:45 <clandmeter> if you are sure other arches are not affected, you could skip it.
2024-03-02 09:11:05 <clandmeter> like with case based arch options
2024-03-02 09:11:08 <clandmeter> config sub
2024-03-02 09:11:58 <clandmeter> i think even with code that is specifically for $arch, but thats a bit tricky as you need to know what the project does. in case of doubth bump it.
2024-03-02 09:12:23 <clandmeter> btw i just looked and saw this commit
2024-03-02 09:12:24 <clandmeter> https://gitlab.alpinelinux.org/huajingyun01/aports/-/commit/09f277c95a0ce5e923e02970975bdc306ce4b350
2024-03-02 09:12:29 <clandmeter> whats this about?
2024-03-02 09:13:26 <clandmeter> does this mean your gov is blocking some connections? sorry im not trying to offend.
2024-03-02 09:39:00 <huajingyun> hi,it doesn't matter, but it's not the reason at all. 
2024-03-02 09:39:09 <huajingyun> sorry for causing misunderstanding,his is the reason for my personal machine, so check is temporarily disabled.when I create MR for aports upstream, I will verify all the fixes again.
2024-03-02 09:39:09 <huajingyun> These issues will be resolved when we get the 3  build machines out to you, I don't think I'll be creating an MR for it.
2024-03-02 09:46:49 <clandmeter> ah ok
2024-03-02 09:46:54 <clandmeter> thx for clearing this up
2024-03-02 09:47:54 <clandmeter> I am just concerned about cn gov and blocking of certain locations which could affect build.
2024-03-02 09:48:17 <clandmeter> i do not have any experience with this and if this affects the builders
2024-03-02 09:59:15 <huajingyun> yeah,some build environment or network problems may cause the check  failed, but this is not the cause of the software package itself.
2024-03-02 09:59:30 <huajingyun> we're trying to resolve these issues, and in any case, thank you very much for asking.
2024-03-05 07:51:41 <huajingyun> hi, I have created  four MRs, can you help review them?
2024-03-05 07:51:45 <huajingyun> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61611
2024-03-05 07:51:45 <huajingyun> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61612
2024-03-05 07:51:45 <huajingyun> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61665
2024-03-05 07:51:45 <huajingyun> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61616
2024-03-05 07:51:51 <huajingyun> thanks.
2024-03-05 21:21:29 <clandmeter> nice work, seems ncopa already merged a few 
2024-03-06 03:34:28 <huajingyun> yeah,  ncopa has merged 2 of the MRs, thank you very much.
2024-03-06 03:34:28 <huajingyun> I will continue to submit new MRs, and try to detail these changes in the MRs, I hope it will not cause any trouble to you.
2024-03-07 11:02:11 <ncopa> I think  https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61715 is a good idea. We just need to be aware of how the private keys are handled. who has access to them.
2024-03-08 02:49:48 <huajingyun> hi ncopa
2024-03-08 02:49:48 <huajingyun> yeah, because I also want to provide this private key (alpine-devel@lists.alpinelinux.org-638db73e.rsa) to you (the infra team), so that  may not have to generate a new key for loongarch later.
2024-03-08 02:49:48 <huajingyun> This is just my idea so I wanted to ask your opinion, I'm not sure if this is the right thing to do.
2024-03-08 07:18:44 <ncopa> hi! who has currently access to the private key? Is it only you, or more people?
2024-03-11 00:49:37 <huajingyun> only myself.
2024-03-11 06:58:55 <huajingyun> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61665  The CI of this MR failed because some packages failed when fetching the source package. 
2024-03-11 06:58:55 <huajingyun> and I checked that these URLs are all valid.  
2024-03-11 06:59:03 <huajingyun> Can you please help me take a look?  thanks.
2024-03-11 07:51:32 <celie> This is a very interesting situation
2024-03-11 07:51:40 <celie> Any idea how many of those aports are hosted on netfilter.org?
2024-03-11 07:51:55 <celie> Those failing aports, that is
2024-03-11 07:53:09 <celie> From a brief glance, i think all 12 of them are netfilter.org projects
2024-03-11 07:53:41 <celie> I have encountered this issue before, and it is caused by busybox wget somehow causing netfilter.org to return a 403
2024-03-11 07:54:56 <celie> abuild-fetch used to use curl, but was switched to busybox wget a few months ago
2024-03-11 07:56:54 <celie> Adding curl to makedepends should allow the build to pass, unless anyone has some time to dig deeper into this curious issue
2024-03-11 08:05:36 <ncopa> we should report it to upstream busybox
2024-03-11 08:15:26 <celie> Using `busybox wget --header 'Accept: */*'` seems to solve the problem, at least that's the difference i can see from comparing the headers busybox wget and curl send
2024-03-11 08:30:46 <ncopa> oh thats a nice find
2024-03-11 08:31:19 <ncopa> I have mentioned it in #busybox on libera
2024-03-11 08:32:07 <celie> Thanks
2024-03-11 08:33:05 <ncopa> the official channel is the mailing list and bugtracker
2024-03-11 08:33:32 <ncopa> we should probably make a fix for busybox
2024-03-11 08:35:36 <celie> This is only for netfilter.org though, probably it has something to do with their web server config
2024-03-11 08:35:46 <ncopa> yup
2024-03-11 09:29:11 <huajingyun> Thanks, as celie said, adding curl to makedepends can solve these failures.
2024-03-11 10:49:45 <ncopa> I reported it here: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15861
2024-03-11 10:53:18 <ncopa> celie: how did you get the headers from busybox wget?
2024-03-11 12:26:24 <ncopa> I have sent patch upstream and to alpine: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61960
2024-03-11 12:29:22 <celie> ncopa: I used netcat to get the headers, let it listen on a port, then made busybox wget visit that
2024-03-11 12:29:52 <ncopa> cool. thanks!
2024-03-11 13:30:47 <celie> As !61960 has been merged, i've opened !61963 to remove the only instance that i could find of curl being added to a netfilter.org aport to fix the busybox wget 403 issue
2024-03-11 13:33:10 <ncopa> builders need to finish firsthttps://build.alpinelinux.org/
2024-03-11 13:36:04 <celie> Yes, but the Go errors in community/ will allow a "retry master" to build and upload the patched main/busybox
2024-03-11 13:42:48 <ncopa> true
2024-03-12 10:41:34 <ncopa> huajingyun: I'm bumping new gcc snapshot. This patch differs from upstream: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/gcc/0038-LoongArch-Fix-MUSL_DYNAMIC_LINKER.patch?ref_type=heads
2024-03-12 10:44:18 <ncopa> ah i figured it out.
2024-03-12 10:45:40 <ncopa> both 0038 and 0039 patches are no longer needed, as they are upstreamed
2024-03-12 11:10:09 <huajingyun> Yes, gcc upstream already includes them. When gcc in alpine is upgrade, it will no longer be needed.
2024-03-15 09:34:05 <cely> Just a quick question (still AFK-ish), i saw the Go MR, and noticed that Go uses "loong64", why can't we use that too?
2024-03-15 09:34:54 <cely> "!loongarch64" is a bit long to type if we have to disable packages for this arch
2024-03-16 06:26:49 <huajingyun> Hi,cely.
2024-03-16 06:26:49 <huajingyun> The reason why we want the arch name to use loongarch64 is mainly because the upstream kernel, compiler gcc, llvm, etc. use loongarch64, so we made it our first choice.
2024-03-16 06:28:37 <cely> Ok, i also guessed it had something to do with the compiler using this identifier
2024-03-16 06:42:55 <huajingyun> Thanks.
2024-03-16 07:30:40 <huajingyun> by the way,we was installing the alpine OS yesterday for the build machines to https://dev.alpinelinux.org/~loongarch/edge-9c13e7/releases/loongarch64/alpine-standard-edge-9c13-loongarch64.iso (the previous install was https: //dev.alpinelinux.org/~loongarch/v3.18/releases/loongarch64/alpine-standard-v3.18.4-loongarch64.iso)
2024-03-16 07:30:46 <huajingyun> Sorry for the delay due to submitting MR and verification, I hope to provide the build machines to you as soon as next week.
2024-03-19 08:12:21 <huajingyun> Hi, clanmeter
2024-03-19 08:12:21 <huajingyun> In addition, can you provide me with their ssh keys by the way? 
2024-03-19 08:12:21 <huajingyun> Thanks.
2024-03-19 08:12:21 <huajingyun> I am applying to open ssh ports for these three build machines. Can you provide me with one or two IP address information? This will be set up for long-term access to the three build machines.
2024-03-19 09:48:41 <ncopa> my keys: https://gitlab.alpinelinux.org/ncopa.keys
2024-03-19 11:19:57 <huajingyun> hi，ncopa，I downloaded, thanks.
2024-03-19 11:19:57 <huajingyun> and can you also provide the corresponding IP address?
2024-03-19 11:25:27 <ncopa> i have dynamic ip address
2024-03-19 11:25:52 <ncopa> but I suppose I could use ipv6?
2024-03-19 11:26:33 <ncopa> it will be a /48 block or something
2024-03-19 11:27:04 <ncopa> or i could use an ssh jump box
2024-03-19 11:27:09 <ncopa> with static ipv4
2024-03-19 11:36:27 <huajingyun> That's good. It's best to use static ipv4.
2024-03-19 12:31:34 <huajingyun> can you provide the static ipv4 address? Thanks.
2024-03-19 12:38:52 <ncopa> 176.58.106.16
2024-03-19 12:40:32 <huajingyun> thanks.
2024-03-21 08:50:49 <huajingyun> ncopa: hi ncopa, is the ssh key of this machine (176.58.106.16) included in ncopa.keys?  If not, can you also send it to me? 
2024-03-21 08:52:11 <ncopa> i think I can use the 176.58.106.16 as jumpbox, using ncopa.keys, yes
2024-03-21 09:12:48 <huajingyun> oh, I'm not sure, we're set up so that currently only 176.58.106.16 can access the build machine
2024-03-21 09:12:53 <huajingyun> let's give it a try
2024-03-21 09:13:15 <huajingyun> please try ssh -p 14079 alpine@111.207.111.194
2024-03-21 10:06:08 <ncopa> debug1: Reading configuration data /etc/ssh/ssh_config
2024-03-21 10:06:08 <ncopa> debug1: Connecting to 111.207.111.194 [111.207.111.194] port 14079.
2024-03-21 10:06:08 <ncopa> OpenSSH_9.1p1, OpenSSL 3.0.8 7 Feb 2023
2024-03-21 10:06:08 <ncopa> $ ssh -v -p 14079 alpine@111.207.111.194
2024-03-21 10:06:21 <ncopa> and there it hangs
2024-03-21 10:08:05 <ncopa> ssh: connect to host 111.207.111.194 port 14079: Operation timed out
2024-03-21 10:24:44 <huajingyun> It seems that there is no permission. Currently, access permission is only opened for 176.58.106.16.
2024-03-21 10:24:44 <huajingyun> So can you try to execute this command based on the 176.58.106.16 platform?
2024-03-21 10:28:27 <ncopa> inet 176.58.106.16/24 scope global eth0
2024-03-21 10:28:29 <ncopa> yes
2024-03-21 10:37:55 <huajingyun> 176.58.106.16 reachable？
2024-03-21 10:39:54 <ncopa> alright. lets try another machine.
2024-03-21 10:42:07 <ncopa> i'll have to et back to that. too busy with the python upgrade. im stressing here
2024-03-21 10:46:12 <huajingyun> ok, thanks, and take your time.
2024-03-21 10:49:02 <huajingyun> Two other build machines:
2024-03-21 10:49:02 <huajingyun> ssh -v -p 14078 alpine@111.207.111.194
2024-03-21 10:49:02 <huajingyun> ssh -v -p 14077 alpine@111.207.111.194
2024-03-21 10:52:27 <huajingyun> If access fails, I will communicate with the colleague responsible for the network.
2024-03-25 06:40:41 <celie> Hello, just wondering, has Rust been bootstrapped on loongarch64 musl?
2024-03-25 08:31:20 <clandmeter> celie: https://dev.alpinelinux.org/~loongarch/edge-9c13e7/main/loongarch64/rust-1.72.1-r1.apk
2024-03-25 08:53:35 <celie> Thanks
2024-03-25 08:54:25 <celie> I've also just realized that i'd already come across !61670 which mentions Rust
2024-03-25 08:55:27 <celie> However, i don't see an MR for adding the loongarch64 triple to main/rust/alpine-target.patch
2024-03-25 09:06:38 <celie> and we had to do the 1.72.1 to 1.74.1 upgrade in a rather roundabout way due to the 32-bit ARM build failures, and as mps has found out, our 1.73.0-r0 will not build 1.74.1-r0
2024-03-25 09:07:19 <celie> (anyone following what we did cannot skip 1.73.0-r1)
2024-03-25 09:08:47 <celie> So, i'm interested in how Loongarch is doing in this regard
2024-03-26 03:06:03 <huajingyun> Hi, celie, my original plan was to wait until rust upstream fully supports loongarch (musl) before creating MR for main/rust/alpine-target.patch.
2024-03-26 03:06:22 <huajingyun> The current status of rust (loongarch) is:
2024-03-26 03:06:33 <huajingyun> 1. Rust upstream has supported loongarch64-unknown-linux-musl target three weeks ago ( https://github.com/rust-lang/rust/pull/121832/files ) 
2024-03-26 03:06:52 <huajingyun> 2. The code is currently in the Tier-3 stage and will be released in the next version 1.78. It is expected to be upgraded to Tier-2 in version 1.79 (when Tier-2 is reached, the source code can be obtained directly from the upstream and built in alpine)
2024-03-26 03:07:29 <huajingyun> Regarding the rust 1.74.1 mentioned above, maybe I missed something. Is there anything I need to do? I saw that aports has been upgraded to 1.77.0
2024-03-26 03:09:11 <huajingyun> The current main/rust in aports needs to be backported and add a small number of patches to support loongarch build, because the dependencies of the current rust 1.77.0 version are not complete. 
2024-03-26 03:09:18 <huajingyun> I am very willing to submit these patches to the upstream of aports to support the build. If everyone agrees to do so.
2024-03-26 03:09:26 <huajingyun> Thanks.
2024-03-26 04:23:29 <celie> Hi, huajingyun, sorry was busy with something else just now.
2024-03-26 04:24:40 <celie> I'm not sure how you build Rust (i noticed that there's an apk for 1.68.0 uploaded for Alpine 3.18), but normally, it needs to be upgraded version by version
2024-03-26 04:25:23 <celie> We were stuck at Rust 1.72.1 for a long time due to 32-bit ARM build failures, which blocked all the other archs as well (even though they were otherwise fine)
2024-03-26 04:26:09 <celie> So, last month, we went from 1.72.1 to 1.76.0, i think in a very short time span of around 3 days
2024-03-26 04:29:29 <celie> Of course, if you're cross compiling Rust, then you can always just use the latest Rust on x86_64, so it doesn't matter
2024-03-26 04:29:57 <celie> but i think Alpine prefers compiling natively, and if you do that within Alpine itself, then Rust will have to be upgraded version by version
2024-03-26 04:32:56 <celie> So, 1.73.0 had 32-bit ARM build failures, which forced us to revert an upstream patch in order to get it to build, and that means if you apply that patch as well, you will need to follow exactly what we did
2024-03-26 04:34:31 <celie> As one Alpine developer found out, you can't build our main/rust 1.74.1-r0 with 1.73.0-r0, you have to follow what we did to the patch in 1.73.0-r1
2024-03-26 04:36:53 <celie> Yes, it's a bit of a mess, maybe someone more familiar with Rust compiler internals could've done it in an easier way, but i don't really think we have anyone in Alpine who fits that criteria
2024-03-26 04:37:06 <celie> at the moment
2024-03-26 04:38:32 <celie> In the middle of all this, the previous Rust maintainer resigned, after being unable to fix the 32-bit ARM problem for a few months, and now it's maintained by a (very small) "team"
2024-03-26 04:42:08 <celie> You mentioned submitting patches, however, if you go version by version, i think that would probably mean you have to submit patches for all the versions between 1.72.1 and 1.77.0
2024-03-26 04:45:57 <celie> In other words, from what i know, unless you are cross-compiling Rust 1.77.0, or you already have a Rust 1.77.0 built for musl (just not with Alpine's target), you cannot go straight from 1.72.1 to 1.77.0, and have to do it one version at a time
2024-03-26 04:50:55 <celie> This is probably also something for Alpine's infra team (or whichever team is working on this) to think about, if we bring the loongarch64 builders online with the current git master, i think it will try to build Rust 1.77.0 (and if the Rust 1.72.1 that huajingyun has uploaded to dev.alpinelinux.org is the latest Rust they have in repo, then the build will fail)
2024-03-26 04:53:47 <celie> If we are not going to build Rust 1.76.0 or 1.77.0 "out of tree" (can't think of a better term at the moment) and add it to the repo, then what i propose to do (not sure how well it will work) is:
2024-03-26 04:55:26 <celie> Disable main/rust for loongarch64 for now, and add a new aport rust-loongarch which will start at version 1.73.0, build that with the main/rust 1.72.1, and then proceed from there until 1.76.0 then use rust-loongarch to build main/rust
2024-03-26 04:55:51 <celie> Something like that
2024-03-26 05:01:06 <celie> I think it's a bit complicated, not sure if it's something our small Rust team is prepared to handle
2024-03-26 05:04:19 <celie> So, maybe it would be better if Loongarch can add a suitable Rust .apk to the repo that can then be used to build main/rust straight away
2024-03-26 05:07:07 <celie> Maybe this can wait for Rust 1.78 (releases.rs says that will be released on 2nd May), the suitable .apk will then have to be either version 1.77 or 1.78
2024-03-26 05:08:57 <celie> Hmm, https://releases.rs/docs/1.78.0/ says that will also bring an LLVM 18 update, so that may complicate things
2024-03-26 05:13:20 <celie> So, i think the sooner we get a .apk newer than https://dev.alpinelinux.org/~loongarch/edge-9c13e7/main/loongarch64/rust-1.72.1-r1.apk the better
2024-03-26 05:17:16 <celie> Anyway, i have been talking for a long time, i guess i should summarize, and the main thing i want to know is if Loongarch has a .apk newer than rust-1.72.1-r1.apk that you can add to the repo
2024-03-26 05:22:06 <celie> or if it's Alpine's Rust team that has to handle the 1.72.1 to 1.77.0 upgrade, in that case, we'll probably need to get the other members of the Rust team to join in the discussion here
2024-03-26 05:28:24 <celie> As for the patches, if they're going to be upstreamed anyway, maybe it is not so important, and we can wait a few months for the upstreaming process to finish
2024-03-26 05:29:57 <celie> but in my opinion, a newer .apk should be a priority if we are to bring the builders online, as many maintainers found out when we were stuck at Rust 1.72.1, the latest version of a lot of aports will not build with 1.72.1
2024-03-26 06:36:22 <huajingyun> Hi,celie, thank you very much for taking the time to clearly explain everything about rust to me. Thank you for raising this issue.
2024-03-26 06:36:22 <huajingyun> currently, the latest version of loongarch64 in the repo is 1.72.1. According to what you said, what I need to do next is to gradually upgrade the rust version in the repo(dev.a.o) to 1.77.0，this is indeed the best solution at the moment.
2024-03-26 06:36:56 <huajingyun> When is the builders expected to be online, I think I need to get up to speed on this
2024-03-26 06:55:59 <celie> I don't really think there is an expected time for that, though i'm not part of the infra team, so can't speak on their behalf
2024-03-26 06:56:45 <celie> It's just that ncopa, at least, is still busy with the Python 3.12 rebuild, so probably doesn't have much time to spare for other things at the moment
2024-03-26 06:58:41 <huajingyun> yes, ncopa said that he has been busy recently
2024-03-26 06:58:52 <celie> huajingyun: When you upgrade Rust to 1.73.0, if you follow what we did in aports, look out for "revert-pr-114382.patch", that is the "hack" we had to use to get 32-bit ARM to build
2024-03-26 06:59:12 <celie> It will very likely not be needed for loongarch64
2024-03-26 07:00:02 <celie> So, if you ignore that patch then you don't need to modify it like we did for 1.73.0-r1
2024-03-26 07:00:24 <celie> and you can probably skip -r1 altogether, and just try building 1.74.1 with LLVM17 straight away
2024-03-26 07:03:07 <huajingyun> okay,thanks
2024-03-26 07:04:37 <celie> In order to save some time for building Rust for 8 architectures, we did 2 things in 1.73.0-r1, one was to switch to LLVM17, the other, modify "revert-pr-114382.patch", if you don't apply that patch to 1.73.0-r0 in the first place, then you don't need to bother with the modifications
2024-03-26 07:05:01 <celie> and very likely the LLVM17 step can be merged into 1.74.0-r0
2024-03-26 07:16:25 <huajingyun> oh,celie, I saw you mentioned cross-compiling before, and I thought of a possibly more convenient way. i can cross-compile rust 1.77.0 through bootstrap.sh, and then build a local rust 1.77.0 based on it.
2024-03-26 07:16:25 <huajingyun> So maybe I don't need to apply the loongarch patch to every version of rust. Can we do this?
2024-03-26 07:27:15 <celie> I think that's up to you
2024-03-26 07:27:23 <celie> If it's doable then i don't see why not
2024-03-26 07:28:18 <celie> As long as that cross-compiled Rust 1.77.0 will build main/rust 1.77.0 with the latest Loongarch patches applied, then it should be ok
2024-03-26 07:29:56 <celie> Maybe you should cross-compile Rust 1.76 instead
2024-03-26 07:30:05 <celie> and then use that to build main/rust 1.77
2024-03-26 07:31:10 <celie> That way you can keep main/rust's pkgrel the same as what we have in Git master
2024-03-26 07:32:45 <celie> I mean, you cross-compile Rust 1.76, put that in the repo, then try to compile main/rust 1.77 (and if it works, then it may be time to think about opening an MR for 1.77 with those patches)
2024-03-26 07:35:13 <huajingyun> okay,I see what you mean, thank you very much
2024-03-26 07:35:22 <celie> You're welcome
2024-03-26 08:48:03 <clandmeter> celie: rust needs to upgrade version by version? 
2024-03-26 08:55:47 <celie> Yes, the only versions that can build a particular version of Rust are the current and previous ones
2024-03-26 08:55:56 <clandmeter> if you could cross compile rust, we could bootstrap from it on the builder i guess. 
2024-03-26 08:56:22 <clandmeter> build i mean
2024-03-26 08:56:31 <clandmeter> i think we do something like that for go
2024-03-26 08:57:01 <clandmeter> but my builder fu is a bit rusty ;-)
2024-03-26 09:47:37 <celie> Now that you've mentioned it, i've remembered something i overlooked, while a Rust 1.76 apk in repo would be the most convenient, it is not the only way to do things
2024-03-26 09:49:37 <celie> main/rust 1.77 should be bootstrappable by extracting into "local rust root", 3 rustup components (https://rust-lang.github.io/rustup/concepts/components.html): cargo, rustc, and rust-std
2024-03-26 09:53:22 <celie> So, if Loongarch has already built those 3 components for either Rust 1.76 or 1.77 with loongarch64 musl, then we can just use those, no need to cross-compile it again
2024-03-26 10:26:25 <ncopa> huajingyun: i was able to log in
2024-03-26 10:26:30 <ncopa> alpine-builder1:~$ uname -a
2024-03-26 10:26:30 <ncopa> Linux alpine-builder1 6.6.15-1-lts #2-Alpine SMP PREEMPT Thu, 20 Apr 2023 10:29:58 +0000 loongarch64 Linux
2024-03-26 10:36:22 <ncopa> huajingyun: can you please also add 172.104.203.112
2024-03-26 12:00:51 <huajingyun> hi,ncopa, that's great!
2024-03-26 12:00:59 <huajingyun> I will contact my colleague add 172.104.203.112
2024-03-26 12:02:01 <ncopa> thank you!
2024-03-26 12:12:10 <huajingyun> You're welcome.
2024-03-26 12:12:15 <huajingyun> I will actively support it, if there is anything I need to do in the future, please let me know, thank you very much.
2024-03-26 12:16:20 <huajingyun> 172.104.203.112 added, you can have a try.
2024-03-26 12:38:47 <ncopa> huajingyun: works! thanks!
2024-03-27 02:03:45 <cely> Hi
2024-03-27 02:12:09 <huajingyun> Hi everyone, cely is my colleague, we will work on alpine together, thanks.
2024-03-27 02:15:51 <cely> I think you meant znley :)
2024-03-27 02:16:20 <cely> Anyway, any progress on the newer Rust version?
2024-03-27 02:18:32 <huajingyun> oh, sorry, it’s znley, I misread it
2024-03-27 02:21:42 <huajingyun> I'm cross-compiling Rust 1.76 and then 1.77 and I thought I'd add this to the repo today.
2024-03-27 02:22:47 <cely> That's good to hear
2024-03-27 02:26:48 <huajingyun> thanks, I'll try to finish it as soon as possible.
2024-03-27 08:04:56 <huajingyun> I just uploaded rust 1.76 and 1.77 to repo.
2024-03-27 08:04:59 <huajingyun> https://dev.alpinelinux.org/~loongarch/edge-9c13e7/main/loongarch64/rust-1.76.0-r1.apk
2024-03-27 08:05:07 <huajingyun> https://dev.alpinelinux.org/~loongarch/edge-9c13e7/main/loongarch64/rust-1.77.0-r0.apk
2024-03-27 08:06:29 <huajingyun> alpine:~$ uname -a
2024-03-27 08:06:30 <huajingyun> rustc 1.77.0 (aedd173a2 2024-03-17) (Alpine Linux 1.77.0-r0)
2024-03-27 08:06:30 <huajingyun> Linux alpine 6.6.15-1-lts #2-Alpine SMP PREEMPT Thu, 20 Apr 2023 10:29:58 +0000 loongarch64 GNU/Linux
2024-03-27 08:06:30 <huajingyun> alpine:~$ rustc --version
2024-03-27 08:07:16 <cely> Very good, thank you
2024-03-27 08:17:47 <huajingyun> As celie mentioned before, is it time to create an MR for rust 1.77 ?
2024-03-27 08:43:57 <cely> I think it would be good, but you already have 1.77 in the repo, so maybe later on when the builders come online, it can be removed so the builders can build 1.77.0 from the patches in the MR
2024-03-27 08:44:45 <cely> but of course, backup the 1.77.0 .apk somewhere in case something goes wrong
2024-03-27 08:50:40 <huajingyun> Oaky, thank you, I will make a backup of the builder before it goes online.