2024-05-02 13:53:00 <cely> huajingyun: Rust 1.78.0 is out, and i've updated my MR, the tarball changed between pre-release and release this time
2024-05-06 09:29:28 <huajingyun> cely:  Sorry for the late response
2024-05-06 09:29:31 <huajingyun> I see it has been updated in upstream aports, I will update and rebuild.
2024-05-06 09:29:41 <huajingyun> Thanks!
2024-05-06 10:01:04 <cely> You're welcome
2024-05-06 10:02:57 <cely> I have made some changes to !65469 (converted the `go get -u`/`go mod tidy` into a patch), please test if it still works on Loongarch.
2024-05-06 10:14:08 <huajingyun> Ok, let me verify it  !65469
2024-05-06 10:17:36 <huajingyun> I verified and it builds fine.
2024-05-06 10:22:01 <huajingyun> Regarding updating golang.org/x/sys, some packages may also be involved, so do we all solve them in this way? 
2024-05-06 12:20:22 <cely> Thanks
2024-05-06 12:20:37 <cely> That is not really easy to answer
2024-05-06 12:20:41 <cely> Are there lots of packages?
2024-05-06 12:25:38 <cely> If there are many packages involved, i would be tempted to say it is up to the individual maintainers, but if it's a manageable amount (less than 50), then maybe solving it with patches would be preferred.
2024-05-06 12:26:02 <ikke> An alternative would be a replace statement 
2024-05-06 12:27:59 <cely> `go mod edit -replace`?
2024-05-06 12:28:12 <cely> Would that be used in prepare() or in a patch?
2024-05-06 12:28:26 <cely> I mean run that, and then diff the contents to a patch
2024-05-06 12:29:35 <ikke> The latter, patches are preferred 
2024-05-06 12:29:47 <ikke> But the patch is simpler 
2024-05-06 12:30:27 <cely> Which remeinds me, i grepped for 'go mod edit', saw that goimapnotify has one, and remembered !65472
2024-05-06 12:30:45 <cely> reminds*
2024-05-06 12:31:14 <ikke> You can even use a workspace 
2024-05-06 12:31:27 <cely> Looks like the `go mod edit` there was removed, and replaced by `go get -u`/`go mod tidy`
2024-05-06 12:32:19 <ikke> go work init . && go work edit -replace
2024-05-06 12:32:39 <ikke> Then you get a file that won't conflict with upstream 
2024-05-06 12:32:56 <ikke> But you'd need to know when to remove it 
2024-05-06 12:33:12 <ikke> You dont want to pin it to q specific version forever 
2024-05-06 12:36:22 <cely> Another question would be, does pkgrel need to be bumped?
2024-05-06 12:37:13 <cely> I think for update_config_sub/update_config_guess, pkgrel is not bumped
2024-05-06 12:38:40 <ikke> It needs to be bumped if the package needs to be rebuilt. If it's just for loongarch, then generally it's skipped 
2024-05-06 12:38:58 <ikke> But bumping dependencies may cause build issues 
2024-05-06 12:39:33 <ikke> That should be covered by CI, though
2024-05-06 12:57:00 <cely> I think for fscrypt, i'll just go with what's in !65469 now, and "go mod/work edit" can be used on other aports
2024-05-07 01:22:42 <znley> ikke: The patch method is better, but when pkgrel is bumped, the patch may need to be regenerated.
2024-05-07 01:24:08 <huajingyun> yes, If use a patch to add loongarch64 support, I'm worried that the patch may not be applied directly after the package is upgraded.
2024-05-07 01:27:54 <znley> In addition, there is no problem useing `go get -u` or `go mod edit`(I prefer `go mod edit`), but should use `go mod tidy` when updating dependencies, simply download cannot solve the dependency problem.
2024-05-07 01:38:52 <cely> When you say "pkgrel is bumped", do you mean an upgrade? because bumping pkgrel is just a rebuild, and source should remain unchanged, so i don't see why the patch would need to be regenerated
2024-05-07 01:45:15 <cely> but as i said, it may be up to the individual maintainers, as the maintainers will be the ones regenerating the patch whenever that's needed (or at least, they should be)
2024-05-07 01:48:11 <cely> Alright, now something for you all to confirm please :)
2024-05-07 01:49:16 <znley> Yes you are right, I confused pkgver:-D
2024-05-07 01:49:26 <cely> I was wondering if maybe it would be better if you got the changes accepted upstream , so i checked my aport that you bumped x/sys for yesterday (fscrypt)
2024-05-07 01:50:00 <cely> https://github.com/google/fscrypt/tree/v0.3.5 seems to be already using x/sys v0.15.0
2024-05-07 01:50:22 <cely> So, please confirm if that will build on Loongarch without the need for any patching
2024-05-07 01:50:33 <znley> I chose a more conservative version when upgrading
2024-05-07 01:51:41 <cely> What i mean is, i just noticed that upgrade, so i am thinking of upgrading, as upstream has already bumped x/sys, i would like to know if the patch can now be removed
2024-05-07 01:54:03 <znley> Yes I just build it and it's totally ok on loongarch64
2024-05-07 01:54:10 <cely> Thanks
2024-05-07 01:54:37 <cely> So, this is an example of upstream already applying the necessary changes, so instead of the patch having to be regenerated, it has to be removed
2024-05-07 01:55:02 <znley> I agree
2024-05-07 02:24:00 <cely> Hmm, now for Rust (thinking of !65524), i think we /sort of/ have a policy of using patches to Cargo.lock
2024-05-07 02:24:38 <cely> or at least, use `--precise <version>`
2024-05-07 06:27:47 <huajingyun> cely:  I updated !65524, added a patch for Cargo.lock.
2024-05-07 06:27:54 <huajingyun>  please help take a look, thank you
2024-05-07 06:34:00 <cely> I think you haven't pushed that change
2024-05-07 06:43:48 <huajingyun> Sorry, I didn't fully understand what you just mentioned about "a policy of using patches to Cargo.lock"
2024-05-07 06:43:58 <huajingyun> Is there any better way we can solve this ?
2024-05-07 06:48:07 <huajingyun> librsvg blocks the building of many packages, so want to solve it by updating libc to 0.2.154.
2024-05-07 06:51:19 <cely> I mean that you should run `cargo upgrade` locally, and make a patch for Cargo.lock
2024-05-07 06:51:26 <cely> s/upgrade/update/
2024-05-07 06:52:21 <cely> That will increase the chances of your MR being accepted (as the maintainer would likely ask you to do the same thing) :)
2024-05-07 06:52:52 <cely> Either that, or you can try `cargo update -p libc --precise 0.2.154`, and see if the maintainer will accept that
2024-05-07 06:53:56 <huajingyun> ok，i understand
2024-05-07 06:53:58 <huajingyun> thanks a lot
2024-05-07 06:54:05 <cely> You're welcome
2024-05-07 06:56:31 <cely> `cargo update -p libc` will upgrade to the latest libc crate (which just happens to be 0.2.154 for now), when 0.2.155 or newer is released, the command will update to that instead, so we usually don't accept this
2024-05-07 06:58:10 <cely> A patch or --precise 0.2.154 will ensure libc is updated only to that specific version
2024-05-07 06:59:16 <cely> and it probably depends on the individual maintainer, whether they will accept --precise 0.2.154, i think a patch will usually be accepted
2024-05-07 07:03:54 <huajingyun> Yes, you are right, so we can see more clearly what we did.
2024-05-07 07:05:24 <cely> and it makes things constant, so there are less variables to reason about
2024-05-07 07:13:04 <huajingyun> yes, thanks.
2024-05-07 07:36:48 <cely> huajingyun: I see you ran a full `cargo update` and made a patch out of that, did `cargo update -p libc --precise 0.2.154` not work?
2024-05-07 07:38:21 <cely> I think just updating libc should be enough, unless there is some other crate that requires updating to have Loongarch support
2024-05-07 07:42:47 <huajingyun> "cargo update -p libc --precise 0.2.154" is fine. 
2024-05-07 07:43:19 <cely> Yes, so a patch with the changes from that should be enough
2024-05-07 07:44:32 <huajingyun> "cargo update" will update the entire Cargo.lock content, thus forming a larger patch.
2024-05-07 07:45:50 <cely> Yes, sorry if i was not more specific earlier, making a patch out of `cargo update -p libc --precise 0.2.154` should be enough
2024-05-07 07:46:51 <cely> There's no need to do the full `cargo update`
2024-05-07 07:50:13 <huajingyun> It's okay, I'll update it again.
2024-05-08 02:57:40 <cely> huajingyun: i have helped you reply to the comment in !65543 about upstreaming the libc bump (it is already in upstream master)
2024-05-08 03:02:28 <huajingyun> hi,cely, thank you so much :)
2024-05-08 03:07:57 <cely> You're welcome
2024-05-08 03:17:41 <huajingyun> Do you know the progress of v3.20 ?  I see from build.alpinelinux.org that build-3-20-arches is still being built
2024-05-08 03:17:50 <huajingyun> Will the recently upgraded rust 1.78 and llvm18 be released in v3.20?
2024-05-08 03:20:51 <cely> Rust 1.78 will be part of 3.20 (we have already patched a few aports (the big ones would probably be Firefox-ESR and Thunderbird) for 1.78 compatibility)
2024-05-08 03:21:11 <cely> LLVM18 should also be part of it, but probably not as default LLVM
2024-05-08 03:25:43 <cely> (Maybe you'll also want to ask the follow-up question, of whether Rust 1.78 will switch to LLVM18, i don't think team/rust has discussed this in depth yet, but i personally think it is a bit too near to the 3.20 release to make such a switch)
2024-05-08 03:28:23 <huajingyun> Yes, that's exactly what I wanted to ask, thank you for your answer
2024-05-11 02:01:41 <ptrc> \o hi everyone
2024-05-11 02:02:14 <cely> Hi ptrc
2024-05-11 02:02:31 <ptrc> huajingyun: i just noticed the new MR for community, and the disabled packages add even more stuff, specifically: biber, okular, peruse
2024-05-11 02:19:10 <huajingyun> hi ptrc, thanks for your reminder
2024-05-11 02:19:15 <huajingyun> i will take a look now
2024-05-11 02:36:49 <huajingyun> ptrc: I added these packages to !65764
2024-05-11 02:36:59 <huajingyun> Thank you
2024-05-11 02:37:34 <huajingyun> qt5-qtwebengine does not support loongarch64 yet. I plan to create a separate MR for qt5-qtwebengine and related software packages.
2024-05-14 07:28:32 <huajingyun> Hi
2024-05-14 07:28:35 <huajingyun> I want to talk to you about build Machines
2024-05-14 07:28:41 <huajingyun> Mentioned in previous discussion with ncopa and clannmeter:
2024-05-14 07:28:41 <huajingyun> huajingyun: okay, let’s try to put it in China first,our network should be able to support it. If the connection is worse, we can directly provide the machines to EU.
2024-05-14 07:28:41 <huajingyun> clandmeter: huajingyun: for our understanding, is it possible to move a machine to EU? lets say if we notice the connection is worse than expected. 
2024-05-14 07:28:51 <huajingyun> I'm worried about putting the Machines in China, which may cause the builder to be inefficient if the connection is slow (the network is not stable yet)
2024-05-14 07:28:51 <huajingyun> plus now accessing these Machines via fixed IPs, I know this will make you Trouble, I really want you to have free access to these Machines, so I'm pushing for this now.
2024-05-14 07:29:02 <huajingyun> Here are my thoughts:
2024-05-14 07:29:02 <huajingyun> I think we can prepare Machines and provide them directly to EU at the same time, so I think the network will no longer be a limitation, and you can access them more conveniently.
2024-05-14 07:29:02 <huajingyun> For the 3 build machines that are now ready, this will still be used as a transitional phase until the new build Machines are already in EU and working properly (this should take a while to complete)
2024-05-14 07:29:13 <huajingyun> For long-term considerations, maybe putting it in EU is a good choice, all of this is just to work better on aports.
2024-05-14 07:29:28 <huajingyun> I want to know what you suggest, do you agree with this?
2024-05-14 07:29:31 <huajingyun> Thanks.
2024-05-14 08:26:57 <ncopa> huajingyun: that sounds like a good plan. having the machines in EU will make things simpler for us
2024-05-14 08:28:30 <ncopa> having access to the machines in china til we have machines in EU will "unblock" us, and let us move forward. This sounds very good
2024-05-14 08:53:00 <huajingyun> ncopa: yeah, thanks
2024-05-14 08:53:14 <huajingyun> then I will apply and promote this job in the near future.
2024-05-14 08:53:25 <huajingyun> this process may take a while,when there are any new developments, I will notify you here. 
2024-05-14 08:53:33 <huajingyun> and if it involves privacy or more details, such as a specific address, please allow me to send you an email
2024-05-14 08:54:40 <ncopa> sounds good. thanks!
2024-05-14 08:55:14 <ncopa> I will try work on loongarch64 in june, after 3.20 is out
2024-05-14 08:55:27 <ncopa> we should be able to have it included in the 3.21 release
2024-05-14 08:56:55 <huajingyun> Okay, that's great!
2024-05-14 09:02:24 <huajingyun> Also, just to double check, how many machines do we need for EU?
2024-05-14 09:19:17 <ncopa> then plan is to move all teh machines from china, right?
2024-05-14 09:20:54 <ncopa> we need CI, dev machine (access for developers to debug issues and test things), edge builder and stable builder(s)
2024-05-14 09:21:26 <ncopa> i think it depends on how powerful those machines are
2024-05-14 09:28:56 <huajingyun> I plan to apply for additional, and these are the same Machines as currently in china.
2024-05-14 09:29:05 <huajingyun> next is the some specs of the build machines：
2024-05-14 09:29:05 <huajingyun> disk: 1sata,4TB
2024-05-14 09:29:05 <huajingyun> CPU: 3C5000*2  (16core*2)
2024-05-14 09:29:05 <huajingyun> memory:128G
2024-05-14 09:40:27 <huajingyun>  ncopa: yes, we move all teh machines  to EU
2024-05-14 09:42:42 <ncopa> are there any dev boards available? would be nice to be able to test kernels, bootloaders, installers etc. without needing to test on the production builder machines
2024-05-14 09:43:16 <ncopa> we have that issue with the riscv64 builders. I want test new kernels, but they often fail, and its cumbersome to test on the production servers
2024-05-14 09:44:24 <ncopa> i suppose qemu could be used too
2024-05-14 09:50:41 <huajingyun> For the dev boards, I need to confirm since I've been testing the kernel on  physical machine
2024-05-14 09:56:58 <huajingyun> or we can prepare 3 machines (as I mentioned specs earlier) for CI, edge builder and stable builder(s), and then add a PC for dev machine and test kernel.
2024-05-14 10:14:37 <ncopa> sounds good
2024-05-14 10:14:51 <ncopa> devboards are not critical i think
2024-05-14 10:50:55 <huajingyun> I think it would be better to use physical machines so we can better help if there are any problems
2024-05-14 11:46:25 <ncopa> Agree
2024-05-14 11:54:58 <huajingyun> ncopa: Is ncopa@alpinelinux.org your usual email address?
2024-05-14 11:55:09 <huajingyun> I just sent an email to this email address. Please check it when you have time. 
2024-05-14 11:55:11 <huajingyun> Thanks.
2024-05-14 12:23:11 <ncopa> i got it. thanks I need to talk to the infra team
2024-05-14 12:27:04 <huajingyun> OK, thanks
2024-05-15 02:14:12 <cely> algitbot: test
2024-05-15 02:14:13 <cely> algitbot: hi
2024-05-17 02:31:51 <cely> It seems you've got one of the first cases in which a developer has requested a pkgrel bump for a Rust libc crate update (!65994)
2024-05-17 02:47:30 <cely> For aports that i maintain, you don't have to worry, if i think a pkgrel bump is needed, i'll add it in myself
2024-05-17 06:16:20 <huajingyun> cely: great, thank you very much
2024-05-17 06:18:05 <cely> You're welcome
2024-05-17 06:41:12 <huajingyun> ncopa:  Hi ncopa, sorry to bother, if you reply to the email please let me know here
2024-05-17 06:41:17 <huajingyun> i guess you've been busy lately, I just wanted to make sure I didn't miss it
2024-05-17 06:41:17 <huajingyun> thanks
2024-05-17 06:53:46 <ncopa> Morning. Yeah just busy, sorry
2024-05-17 07:01:40 <huajingyun> That's okay, just stick to your schedule
2024-05-17 07:01:42 <huajingyun> I'll keep waiting
2024-05-17 08:21:32 <huajingyun> Hi, i just noticed that Rust libc is set to "Yanked" in https://crates.io/crates/libc/0.2.154
2024-05-17 08:21:35 <huajingyun> This means that execution of "cargo update -p libc --precise 0.2.154" will fail
2024-05-17 08:21:40 <huajingyun> discussed here: https://github.com/rust-lang/libc/issues/3608
2024-05-17 08:21:49 <huajingyun> Fortunately, the MRs we currently create are all as patches (thanks to cely's suggestion), and their compilation will not be affected.
2024-05-17 08:22:10 <huajingyun> For the remaining Rust libc related packages, I'm not sure, or we wait for the next libc  to be released
2024-05-17 08:23:35 <cely> Are there still many aports left to patch?
2024-05-17 08:23:53 <huajingyun> or need to modify Cargo.lock manually as patch(git diff) instead of "cargo update"
2024-05-17 08:27:14 <huajingyun> Yes, it seems that community has more than 90 packages.
2024-05-17 08:27:56 <cely> Ok
2024-05-17 08:32:57 <huajingyun> These may not be comprehensive statistics, but I think we need to plan what to do with them
2024-05-17 08:33:05 <huajingyun> wait next libc or "git diff"
2024-05-17 08:37:04 <cely> I guess it depends how quickly upstream is able to release a new version of libc
2024-05-17 08:38:41 <cely> Anyway, if any of the aports left to patch are maintained by me, feel free to open an MR with the "git diff" method, i don't mind accepting that
2024-05-17 08:39:10 <cely> As for the other maintainers, maybe some of them will not want to accept something that has been "yanked"
2024-05-17 08:40:51 <huajingyun> Yes, I thought so too
2024-05-17 08:43:10 <huajingyun> Thank you cely
2024-05-17 08:49:52 <cely> No problem
2024-05-18 02:17:52 <huajingyun> A good news is that libc has released 0.2.155 
2024-05-18 02:17:52 <huajingyun> see：
2024-05-18 02:17:52 <huajingyun> https://crates.io/crates/libc/0.2.155
2024-05-18 02:17:52 <huajingyun> https://github.com/rust-lang/libc/releases
2024-05-18 02:59:03 <znley> ikke: hello, I make a mr https://gitlab.alpinelinux.org/kdaudt/bolt/-/merge_requests/1 to support loongarch64 when building bolt related packages.  This also requires generate a tag.
2024-05-18 03:12:05 <celie> That's good news (libc crate)
2024-05-18 05:32:55 <ikke> znley: V
2024-05-18 05:32:57 <ikke> https://gitlab.alpinelinux.org/kdaudt/bolt/-/tags/v1.3.4
2024-05-18 06:08:48 <huajingyun> Thanks
2024-05-18 07:05:27 <znley> ikke: I am sorry I make a mistake, I forgot rename package name on bolt_loong64.go. https://gitlab.alpinelinux.org/kdaudt/bolt/-/merge_requests/2
2024-05-18 07:22:38 <ikke> https://gitlab.alpinelinux.org/kdaudt/bolt/-/tags/v1.3.5
2024-05-20 04:36:18 <cely> Sometimes i feel how much of a hassle it is for you all, having to deal with so many different maintainers that ask all sorts of things (that is, if they even reply at all)
2024-05-20 04:38:38 <cely> So, to lighten that a bit, i've merged 5 Loongarch MRs in a go, which includes those for my aports, and for other maintainers who are inactive or busy with other things
2024-05-20 04:52:02 <cely> I've also been occupied with some things these few days..working on Perl 5.40 and SQLite tests
2024-05-20 07:41:10 <huajingyun> cely:  hi cely, thank you so much for taking the time to do this
2024-05-20 07:41:29 <cely> No problem
2024-05-20 07:43:29 <huajingyun> This is indeed the trouble we face,we are create new MRs , but I have to spend time checking the status of the MRs that have already been submitted.
2024-05-20 09:42:25 <cely> !66259's cargo-update.patch needs a more appropriate name :)
2024-05-20 09:44:16 <cely> and pkgrel also shouldn't be 16
2024-05-20 11:06:55 <huajingyun> sorry, my mistake
2024-05-20 11:20:34 <huajingyun> cely:  I mixed up the patch name, thanks for reminding
2024-05-20 12:55:54 <cely> You're welcome
2024-05-21 13:35:00 <cely> Oops, seems you have opened an MR for an aport maintained by @itoffshore (!66324), who is one of the maintainers who is still around, but does not regularly approve MRs
2024-05-21 13:37:26 <cely> I think _maybe_ you should look for all aports maintained by @itoffshore, and put all modifications needed for them in one MR, then tag them specifically asking for a "LGTM" reply
2024-05-21 13:39:27 <cely> Otherwise, asking for approval for each MR will take some time, as when asked for approval, they usually instead reply that they don't have privileges to merge
2024-05-21 13:39:32 <cely> At least, that's what i've observed
2024-05-21 13:41:55 <cely> Maybe other developers have better suggestions, or maybe @itoffshore's MRs can just be merged without explicit approval
2024-05-21 13:53:11 <cely> I think @itoffshore has been told a long time ago that approval is optional
2024-05-21 16:00:06 <mps> cely: sometimes I merge without any asking others MR if I think MR is ok
2024-05-21 16:01:04 <mps> alpine is not like other distros with formalities
2024-05-21 16:02:47 <mps> but we should with base and system pkgs, ofc
2024-05-21 16:03:00 <mps> should be careful*
2024-05-21 16:12:55 <cely> Ok
2024-05-21 16:14:23 <cely> Maybe we need to discuss how we're going to handle the @itoffshore MRs (as it relates to Loongarch), so we are all on the same page, and don't ask for approval sometimes and sometimes not
2024-05-21 16:14:35 <ikke> Not all maintainers will like that
2024-05-21 16:18:37 <cely> @itoffshore is under the impression that approval is optional, as someone told them that a while ago, and so has (from what i see) avoided giving approval even when asked
2024-05-21 16:19:04 <cely> and instead replies "no permission to merge", "no permission to press approve button"
2024-05-21 16:20:29 <mps> ofc, best practice is to ask maintainer and if s/he is quiet for long then we could merge or even consult other devs
2024-05-21 16:21:53 <mps> cely: sometimes I approve MR for pkgs of other maintainers, no one ever complained
2024-05-21 16:29:33 <cely> Yes, i've noticed that you and @jirutka sometimes approve the MRs assigned to other maintainers
2024-05-22 01:52:51 <huajingyun> Hi, thank you for your suggestions
2024-05-22 01:52:54 <huajingyun> When we make changes for loongarch64, we are careful to ensure that they do not affect compilation for other architectures
2024-05-22 01:53:01 <huajingyun> Some created MRs are assigned to maintainers who do not have merge permissions, which does take some time.
2024-05-22 01:53:15 <huajingyun> For the aports maintained by @itoffshore, I will first look at the remaining packages that need to create MR
2024-05-22 01:53:15 <huajingyun> And create an MR for them, which will make the merge faster as cely said
2024-05-22 01:59:34 <cely> @itoffshore was given access to the "Approve" button yesterday, so hopefully that will help make things smoother
2024-05-22 02:07:14 <huajingyun> That's great, hope
2024-05-22 20:09:38 <mps> znley: I approved ax25-libs MR. if you want you can merge
2024-05-23 00:27:46 <znley> Thank your!
2024-05-23 01:35:24 <huajingyun> Just saw that v3.20.0 has been released
2024-05-23 01:41:38 <cely> Yes, it was released yesterday
2024-05-23 01:42:15 <cely> Could have been released the day before, but a last minute bug/regression in Busybox awk was found
2024-05-23 01:50:21 <huajingyun> That's good news!
2024-05-23 01:51:40 <cely> :)
2024-05-23 03:06:55 <cely> znley: it's binaryen, not binarygen (!66414)
2024-05-23 03:38:30 <znley> re-edited.
2024-05-23 04:16:51 <cely> The commit message also needs to be amended
2024-05-24 06:07:53 <huajingyun>  ncopa:  hi, ncopa, I am going to upload the latest built  packages to the three builders recently, and then I will send you the detailed information about the 3  machines again
2024-05-24 12:33:12 <cely> !66479 seems like we have someone new working on Loongarch MRs :) and on testing this time
2024-05-24 13:10:02 <fossdd> thats cool
2024-05-25 01:03:06 <huajingyun> cely: Yes, we added several members yesterday for testing and should be creating more MRs in the near future
2024-05-25 01:03:21 <huajingyun> I wanted to talk about this here yesterday, but was delayed by a sudden work meeting.
2024-05-25 01:04:14 <cely> No problem
2024-05-25 01:05:49 <huajingyun> Thanks
2024-05-25 03:36:45 <cely> Just wondering, how many new members did you add? So far, i have seen 3 new names opening MRs: Zewei, Xuhui, Xiaojuan
2024-05-25 03:42:16 <huajingyun> Yes, we have added 3 new members: Zewei, Xuhui, Xiaojuan
2024-05-25 03:43:51 <cely> Alright, good to know :)
2024-05-25 03:44:59 <huajingyun> We will always work for aports, if there is anything that needs to be improved for MRs please let me know
2024-05-25 03:45:05 <huajingyun> Thank you
2024-05-25 03:59:39 <cely> Maybe things will be a bit slower since N Copa is on holiday for a week or two
2024-05-25 04:00:28 <cely> Anyway, i've assigned a few of the Loongarch MRs to maintainers that the bot did not assign automatically
2024-05-25 04:01:48 <cely> Not sure if that's something we want to do all the time, but since the bot already assigns whatever it can auto-detect, i figured i would just follow suit
2024-05-25 04:03:19 <cely> Some of the maintainers that the bot doesn't auto-assign like @omni have commit access, so they should be able to look through and merge MRs assigned to them when they find the time
2024-05-25 04:04:47 <cely> Others that i assigned, i'm not so sure, maybe they are not even aware of the TSC decision to support Loongarch
2024-05-25 04:05:05 <cely> but still, probably good to let them know about the changes
2024-05-25 06:27:15 <huajingyun> Oh cely, thank you for doing this
2024-05-25 06:27:20 <huajingyun> I should have guessed that N Copa might be on holiday because there was no response to my message to him here yesterday.
2024-05-25 06:27:22 <huajingyun> This would be easier if there was a way to notify all maintainers about loongarch64
2024-05-25 06:28:03 <huajingyun> until then if some maintainers have questions about loongarch64 we will explain it in MR
2024-05-25 06:29:51 <cely> That should work
2024-05-25 06:30:32 <cely> I think N Copa was actually still around when you sent your message, but was probably busy finishing some other things before going on holiday
2024-05-25 06:42:31 <huajingyun> Ok，thanks for telling me this
2024-05-25 06:42:36 <huajingyun> before N Copa mentioned that will be working on loongarch64 in June
2024-05-25 06:42:42 <huajingyun> then I should be more fully prepared before he comes back from holiday, regarding MRs or builders
2024-05-25 06:43:58 <cely> By the way, for pkgrel bumps, i think it is only some maintainers that request them, so (in my opinion) your team should continue not bumping pkgrel until requested
2024-05-25 06:47:24 <huajingyun> No problem
2024-05-25 06:50:09 <cely> One question i've wanted to ask (don't remember if i've asked it before) is, does Erlang and Elixir work on Loongarch64? (i maintain Erlang)
2024-05-25 06:54:56 <huajingyun> Yes, it has been built
2024-05-25 06:54:58 <huajingyun> https://dev.alpinelinux.org/~loongarch/edge/community/loongarch64/
2024-05-25 06:56:18 <cely> Ok, that's good to know
2024-05-25 06:56:55 <cely> I should just check that page the next time i have a similar question :)
2024-05-25 07:01:30 <huajingyun> yes,you can
2024-05-25 07:01:34 <huajingyun> I've been following the latest aports upstream and uploading the built packages here
2024-05-26 20:35:51 <fossdd> wow this list is quite impressive for such a new arch
2024-05-27 04:26:01 <cely> For !65477, i think @andypost means add a comment explaining why Loongarch is disabled in the APKBUILD itself
2024-05-27 05:58:46 <cely> huajingyun: i'm testing out Rust with LLVM18 in !66627 (it may not be merged that quickly though, as there seems to be some issues with s390x and x86_64)
2024-05-27 06:14:07 <huajingyun> cely:  Ok, I will verify !66627 on loongarch64
2024-05-27 06:17:56 <cely> Thanks :)
2024-05-27 06:30:52 <cely> The patch for !66630 is not checked into git
2024-05-27 06:32:44 <huajingyun> You're welcome, I'm happy to do it.
2024-05-27 06:33:07 <huajingyun> OK, let me see
2024-05-27 09:25:20 <huajingyun> cely: I see you helped reply to some comments, thank you very much
2024-05-27 09:25:30 <huajingyun> also, I just verified !66627 and it's fine on loongarch64
2024-05-27 09:25:38 <huajingyun> alpine:~/Celeste/aports$ rustc --version
2024-05-27 09:25:38 <huajingyun> rustc 1.78.0 (9b00956e5 2024-04-29) (Alpine Linux 1.78.0-r1)
2024-05-27 09:32:24 <cely> That's good :)
2024-05-28 09:30:08 <huajingyun> cely:  shadowsocks-rust may needs to update sha512sum  !66766
2024-05-28 11:58:49 <cely> huajingyun: It seems upstream changed build-release.yml and Dockerfile
2024-05-28 12:01:26 <cely> Maybe i would like to hold out on this one, as the builders already have the old file cached on https://distfiles.alpinelinux.org/
2024-05-28 12:01:48 <cely> Would it be possible to solve it on your side with something like distfiles?
2024-05-28 12:04:57 <cely> I mean downloading the old file from https://distfiles.alpinelinux.org/ into your version of distfiles
2024-05-28 12:17:29 <cely> Looking at /usr/bin/abuild, i see there's a DISTFILES_MIRROR variable, and i tried `DISTFILES_MIRROR=https://distfiles.alpinelinux.org/distfiles/edge abuild unpack`, and it downloaded the file from there instead
2024-05-28 12:21:17 <cely> Could you consider doing something like that (or setting up your own distfiles mirror) so your setup can be closer to what the builders use (the builders will use the cached file from distfiles.alpinelinux.org, so they are not affected by the changed checksum)
2024-05-29 00:49:14 <huajingyun> cely: OK, I understand, I will do as you said. 
2024-05-29 00:49:17 <huajingyun> Thank you
2024-05-29 01:03:05 <cely> Just wondering, znley, are you able to resolve the thread you replied to in !66731?
2024-05-29 01:03:29 <cely> huajingyun: You're welcome
2024-05-29 01:11:21 <cely> For cargo-modules, i was just about to merge when your reply popped up, creating an unresolved thread, so i am interested to know if you can resolve it
2024-05-29 01:12:35 <cely> If you can, would make it easier if you resolve the threads as you create them (unless you really intend for them to be unresolved)
2024-05-29 01:19:53 <huajingyun> znley: you should resolve it
2024-05-29 01:22:39 <znley> cely: Have done.
2024-05-29 01:22:53 <cely> Thanks
2024-05-30 02:23:30 <celie> For !66877, if Loongarch is disabled, why does the libc crate still need to be updated?
2024-05-30 07:15:26 <huajingyun> Sorry,  I've told @yzewei to update
2024-05-30 07:16:13 <cely> Ok :)
2024-05-30 07:17:56 <huajingyun> Sometimes there may be errors in processing various types of packages. Thank you for discovering it. we will be more careful.
2024-05-30 07:19:42 <cely> You're welcome