2024-04-06 10:23:41 <mps> huajingyun: is the patch Add-loongarch64-support.patch in alpine for lxc merged upstrem. It looks like it is. I'm building new lxc 6.0.0
2024-04-06 10:39:47 <mps> !63625
2024-04-07 01:28:33 <huajingyun> mps: hi, this is good, lxc upstream released 6.0.0 four days ago, thank you for upgrading it.
2024-04-07 06:47:28 <mps> huajingyun: thanks for confirmation
2024-04-08 10:48:13 <ncopa> the loongarch64 patch seems to break the tests: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63749
2024-04-08 10:53:59 <ncopa> huajingyun: re the loongarch64 build server. Here is what I think we need to do:
2024-04-08 10:54:27 <ncopa> install lxc, and set up lxc bridge interface
2024-04-08 10:55:04 <ncopa> create a build-edge-loongarch64 lxc container (similar to what we do on our other builders) and move the currently built packages to there
2024-04-08 10:55:42 <ncopa> install aports-build and mqtt-exec
2024-04-09 01:15:59 <znley> I'm dealing with this problem: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63749
2024-04-09 01:20:50 <huajingyun> ncopa: okay, I will install the corresponding packages for the build server as soon as you mentioned, thanks.
2024-04-09 01:46:53 <celie> znley: Is !63754 not enough to fix that?
2024-04-09 03:05:11 <znley> Yes, I believe !63754 is enough. It also passed the test on loongarch64.
2024-04-09 03:27:42 <znley> It will add a huge patch building openjdk with server mode on loongarch64. !63346 so I chose the simpler zero mode. What do your think?
2024-04-09 04:11:39 <celie> huajingyun: For !63800, you usually have to rename the file as well (most of the time we rename $pkgname-$pkgver.tar.gz before :: in source to something like $pkgname-$pkgver-1.tar.gz)
2024-04-09 04:12:41 <celie> This is because the old file is still cached at https://distfiles.alpinelinux.org/distfiles/edge/lua-pty-1.2.2.tar.gz, and the builders will use the cached file if available
2024-04-09 04:16:18 <celie> If you don't rename it then i think you would need ikke (who has access to distfiles and can remove the cached file) to merge your MR, others who can merge but don't have access to distfiles can't do that
2024-04-09 04:21:35 <celie> I mean, they would have to rename it before merging anyway
2024-04-09 06:07:16 <huajingyun> hi  celie, thanks for the reminder, I've renamed it
2024-04-09 06:14:22 <celie> You're welcome
2024-04-10 07:25:05 <huajingyun> ncopa: hi, ncopa
2024-04-10 07:25:24 <huajingyun> I have created build-edge-loongarch64 lxc container for three build machines and put the currently built packages in /home/alpine/edge-9c13e7 of alpine-builer1 (ssh -v -p 14079 alpine@111.207.111.194) server In the directory, I will also synchronize subsequent software package updates here regularly.
2024-04-10 07:25:41 <huajingyun> In addition, I created a local repo in alpine-builder1, also updated /etc/apk/repositories in the lxc container, and installed install aports-build and mqtt-exec
2024-04-10 07:25:49 <huajingyun> can you take a look at it when you're free? sorry I guess you are still busy recently.
2024-04-10 07:26:05 <huajingyun> because I'm not sure if what I did is consistent with what you asked, please let me know if there is anything you need me to do. 
2024-04-10 07:26:11 <huajingyun> Thank you!
2024-04-10 07:27:07 <mps> huajingyun: do you think we should add to linux-edge arch loongarch
2024-04-10 07:30:45 <mps> and I guess we will not have longarch release 3.20-stable?
2024-04-10 07:30:55 <mps> loongarch*
2024-04-10 07:38:20 <huajingyun> I hope to add it in release 3.20-stable if we can catch up
2024-04-10 07:38:29 <huajingyun> I'm guess 3.20-stable should be released in mid-May, right?
2024-04-10 07:39:31 <mps> probably
2024-04-10 07:47:58 <huajingyun> do you know when the 3.20-stable code will be frozen?
2024-04-10 07:48:51 <mps> no, I don't but I guess at the may beginning
2024-04-10 07:49:28 <mps> with some exceptions all looks fine for freeze, at least looks to me
2024-04-10 07:50:03 <mps> maybe python 12 not yet
2024-04-10 07:50:44 <mps> but ncopa and ikke will know better
2024-04-10 07:52:00 <celie> Is there a code freeze? my impression is that Alpine stables duplicate edge (leaving out testing) until the last moment before the release is tagged.
2024-04-10 07:52:59 <mps> celie: it is not freeze like debian and other distros, but yes, edge freezes some time before stable release
2024-04-10 07:53:33 <mps> i.e. not 'allowed' to add big and important changes
2024-04-10 07:53:44 <mps> more like this
2024-04-10 07:53:56 <celie> Yes, i guess that's what i had in mind
2024-04-10 07:55:55 <celie> So, more concretely, perhaps Rust 1.78.0 could still get in (i think that's also planned for May), but if it also switches to LLVM18 and that's too big a change, then probably just Rust 1.78.0 without LLVM18 will go into Alpine 3.20
2024-04-10 07:56:28 <huajingyun> mps: celie: I think it should be as you said,  thanks.
2024-04-10 07:57:19 <mps> llvm18 would be big change imo
2024-04-10 07:57:45 <celie> https://releases.rs/ says Rust 1.78.0 will be released on 2nd May, so unless Alpine 3.20 beats that, it will probably get in
2024-04-10 07:58:48 <mps> I'm against merging rust 1.78 without very strong reason. we want stable release to be ... hmmm ... stable
2024-04-10 07:59:07 <huajingyun> upstream rust should release a new version every 6 weeks.
2024-04-10 08:00:11 <mps> we must keep in mind that kernel get more and more rust code and kernel is 'anchored' for particular rust versions
2024-04-10 08:00:15 <celie> On the other hand, Perl 5.40, also planned for May i think, but don't know where i would find a date for that, probably won't make it into 3.20
2024-04-10 08:02:37 <mps> I have not so short list of 'big' packages which will have major releases in may :)
2024-04-10 08:03:07 <celie> Even if Rust 1.78.0 doesn't go into 3.20, it will probably be upgraded to that later on due to https://gitlab.alpinelinux.org/alpine/tsc/-/issues/21
2024-04-10 08:03:46 <celie> I would be interested in seeing that list
2024-04-10 08:05:46 <mps> qemu, perl, mesa ... from the head
2024-04-10 08:06:34 <celie> Ok
2024-04-10 08:08:03 <mps> just pushed new crystal release to CI
2024-04-10 08:08:28 <celie> Yes, i saw that
2024-04-10 08:09:12 <celie> I saw the new release and thought it would be better if you handled it because you can also update _bootver
2024-04-10 08:09:49 <mps> yes, I did all this
2024-04-10 08:10:12 <mps> and it was easy this time
2024-04-10 08:10:32 <celie> That's good...for now
2024-04-10 08:11:45 <mps> also crystal is not so much important for release because not much depends on it in alpine
2024-04-10 08:54:55 <ncopa> hi!
2024-04-10 08:55:40 <ncopa> we branch the stable branches same time as we tag the 3.20 release
2024-04-10 08:56:22 <ncopa> the idea with that it becomes in everybodys best interest to get the release out so everybody can go back developing new stuff afterwards
2024-04-10 08:56:50 <ncopa> if we'd branch before the release, majority would continue do the git master/edge and ignore the stable release
2024-04-10 08:57:17 <ncopa> we set up the builder ~1 month before the release. I am a 10 days late with that already
2024-04-10 08:57:47 <ncopa> when I set up the 3.20 builders i start from scratch. build everything from zero
2024-04-10 08:58:27 <ncopa> that means that when I start with bootstrapping the toolchain and abuild, we effectively have a code freeze of the *toolchains*
2024-04-10 08:58:49 <ncopa> we should not update gcc, binutils, rust, llvm, abuild, etc
2024-04-10 08:58:54 <ncopa> or gnu make, cmake etc
2024-04-10 08:59:05 <ncopa> the tools that generates code
2024-04-10 08:59:16 <ncopa> i have called that a "soft freeze"
2024-04-10 08:59:59 <ncopa> during that month the builders ar building the 3.20 release, we should not do any significant updates/changes in the build tools. they are "frozen"
2024-04-10 09:00:32 <ncopa> i also need to tag a new abuild release before that happens
2024-04-10 09:01:22 <ncopa> for loongaarch64, i think what we need to do now, is set up a proper build-edge-loongaarch64, and plug it to the build infra
2024-04-10 09:02:12 <ncopa> we use dmvpn for the resot of our infra, so our infra can route an internal network. its mosly for convenience
2024-04-10 09:02:37 <ncopa> i dont know if we can set up ipsec/dmvpn to the loongarch64 machines?
2024-04-10 09:03:11 <ncopa> its a mesh ipsec vpn, so it will establish ipsec connections to any other server on demand.
2024-04-10 09:03:43 <ncopa> if we cannot do that, we could maybe set up a wireguard tunnel?
2024-04-10 09:04:06 <ncopa> would be nice to be able to route to the loongarch64 machines with internal address
2024-04-10 09:05:11 <mps> wireguard would be ok for beginning I think
2024-04-10 09:05:39 <ncopa> yeah. but it might require firewall configuraion on build server site
2024-04-10 09:38:45 <huajingyun> ncopa: what port does dmvpn need to use? we need to set up some whitelists first.
2024-04-10 09:45:32 <ncopa> proto ESP + UDP port 500, 4500
2024-04-10 09:46:00 <ncopa> but the challenge is that it is a mesh network, and we cannot maintain a full list of all IPs
2024-04-10 09:46:39 <ncopa> source/dest ip needs to be any IP
2024-04-10 09:47:14 <ncopa> if that is not possible, we could set up a wireguard tunnel only and route via a single machine
2024-04-10 09:50:11 <huajingyun> I think it's ok and I'm applying to the network administrator. 
2024-04-10 09:51:33 <ncopa> awesome!
2024-04-11 06:23:21 <huajingyun> hi,ncopa
2024-04-11 06:23:39 <huajingyun> I submitted this application yesterday and have received support and approval
2024-04-11 06:23:51 <huajingyun> you can try to deploy ipsec/dmvpn or wireguard tunnel on 3 build machines.
2024-04-11 06:23:59 <huajingyun> If you need any network conditions, you can give us feedback.
2024-04-11 06:24:04 <huajingyun> Thanks.
2024-04-11 06:24:54 <ncopa> awesome! thank you!
2024-04-11 06:28:35 <huajingyun> you're welcome
2024-04-15 10:30:50 <ncopa> huajingyun: i have moved the build-edge-loongarch64 to /var/lib/lxc so it is more similar to other builders, and I have changed the subnet to 172.16.32.0/24 (is this subnet ok ikke?)
2024-04-15 10:31:07 <ncopa> for some reason the lxc container does not get DHCP lease atm
2024-04-15 10:31:40 <ncopa> oh I think I know why
2024-04-15 10:37:38 <ncopa> its fixed now
2024-04-15 10:59:28 <ikke> .31 and up should be available
2024-04-15 11:24:28 <ncopa> thanks!
2024-04-15 11:46:13 <ikke> If they are connected via LAN, a single subnet may suffice 
2024-04-15 11:59:42 <cely> Which will we be getting first? A Loongarch CI runner or a builder?
2024-04-15 14:17:48 <ncopa> i was thinking build-edge-loonarch64 first
2024-04-15 14:17:56 <ncopa> but that is an excellent question
2024-04-15 14:18:10 <ncopa> maybe it makes most sense to add a CI first?
2024-04-15 14:18:21 <ncopa> the problem now is the 3.20 release. I am already 2 weeks late
2024-04-15 14:18:43 <ncopa> maybe we should wait with loongarch64 til after 3.20 is out the door
2024-04-15 14:19:11 <ncopa> i think we will have a lot to fix for riscv64 already
2024-04-15 14:19:33 <ncopa> so maybe we should be realistic and do loongarch64 after the 3.20 release
2024-04-15 14:39:10 <mps> looks like your thinking is right
2024-04-16 02:41:14 <huajingyun> hi
2024-04-16 02:41:27 <cely> Hi
2024-04-16 02:41:30 <huajingyun> ncopa: I created build-edge-loongarch64 under /home mainly because there is more disk space in the /home directory (I mounted /dev/sda to /home before)
2024-04-16 02:41:30 <huajingyun> of course, consistency with other builders should be better managed, just follow your rules, thank you.
2024-04-16 02:41:47 <huajingyun> so can build-edge-loongarch64 now be connected to the build infra? I just want to know if the network conditions of loongarch64 builder can be supported.
2024-04-16 02:42:06 <huajingyun> although I very much hope that loongarch64 can keep up with the v3.20 release, I can also understand your decision. as you mentioned before, the time to deal with all arches is tight.
2024-04-16 09:06:48 <huajingyun> hi, I have a few questions about the release
2024-04-16 09:07:55 <huajingyun> Will there be requirements similar to the following before alpine loongarch64 or other new architectures are released later? such as
2024-04-16 09:08:02 <huajingyun> 1. For packages: at least how many packages need to be compiled before release or the proportion of packages？ It can be about main, community (or testing)
2024-04-16 09:08:13 <huajingyun> 2. For docker images: this is clear, according to ikke mentioned before, we need to contact docker official and provide build machines, does this have to be completed before release?
2024-04-16 09:08:36 <huajingyun> 3. For iso image: does alpine have any regulations? Because I saw that riscv64 is only in edge and not in the specific release  (eg: v3.19), https://dl-cdn.alpinelinux.org/alpine/edge/releases/riscv64/, and it only minirootfs.
2024-04-16 09:08:49 <huajingyun> Thanks.
2024-04-16 09:22:11 <mps> huajingyun: riscv64 didn't yet released. First time it will be with 3.20 stable
2024-04-16 09:22:58 <mps> also, testing is never included in releases, it is always edge
2024-04-16 09:24:35 <mps> also note that there is no linux-lts for riscv64
2024-04-16 09:27:16 <mps> how will be iso image built for riscv64 I have no idea
2024-04-16 09:28:12 <huajingyun> mps:  oh, thanks, I noticed that riscv64 is disabled in linux-lts
2024-04-16 09:29:23 <mps> linux-edge run on some riscv64 boards, linux-starfive on starfive visionfive 2
2024-04-16 09:29:41 <mps> and in qemu
2024-04-16 09:33:28 <huajingyun> sorry,I didn't understand what you mentioned about linux-starfive? Can you talk about it?
2024-04-16 09:35:49 <mps> linux-starfive is pkg (kernel) in testing
2024-04-16 09:40:35 <huajingyun> I see, this seems to only apply to riscv64
2024-04-16 09:43:37 <mps> yes
2024-04-16 09:44:49 <mps> it is kernel for board some of us got to test and port alpine to riscv64
2024-04-16 09:48:16 <huajingyun> i see,thank you for your answer:-D
2024-04-16 09:50:33 <mps> np
2024-04-16 09:50:47 <huajingyun> questions 1 and 2 I mentioned earlier, do you know anything about this?
2024-04-16 09:55:06 <mps> for 2 I have no idea
2024-04-16 09:55:50 <mps> for 1, all packages in main and community must pass builders
2024-04-16 09:56:15 <mps> all pkgs which are enabled for arch, I mean
2024-04-16 09:56:39 <mps> if some pkgs doesn't enabled for arch they are skipped
2024-04-16 10:06:47 <ncopa> I don’t think we will have time to squeeze in loongarch64 for alpine 3.20. But we should be able to enable the edge builder short after 3.20 release
2024-04-16 10:07:08 <ncopa> We are already late with the 3.20
2024-04-16 10:07:34 <mps> also I think so
2024-04-16 10:08:17 <mps> we have to concentrate on bugs and fixes for release
2024-04-16 10:10:52 <huajingyun> yes, so  we can plan adding loongarch64 in release after 3.20, such as v3.20.1 , right?
2024-04-16 10:12:48 <mps> 3.21
2024-04-16 10:14:05 <mps> v3.20.1 will upgrade to 3.20 (sec and bug fixes)
2024-04-16 10:15:22 <mps> https://alpinelinux.org/releases/
2024-04-16 10:19:00 <huajingyun> Referring to the previous release time, 3.21 is expected to be released in November or December this year.
2024-04-16 10:21:14 <huajingyun> but that's also good, so we have more time to make alpine loongarch64 better. thanks
2024-04-16 10:28:11 <ncopa> Yes, 3.21 in November 
2024-04-16 10:28:56 <ncopa> but we can have edge up much sooner than that
2024-04-16 10:30:36 <huajingyun> yes，thanks
2024-04-16 10:30:43 <huajingyun> at present, in addition to fixing the failed package, last week I also installed an alpine iso machine locally and started to continuously build the latest aports
2024-04-16 10:30:46 <huajingyun> so that we can know the latest build status of loongarch64 as soon as possible.
2024-04-16 10:32:47 <huajingyun> another question, for iso, how long before release do we usually start testing? Is this done by the infrastructure team? 
2024-04-16 10:32:56 <huajingyun> what do we need to do in advance if our help is needed?
2024-04-16 10:35:19 <ncopa> Official iso releases are usually done as release candidates, after the builders are done with all the packages
2024-04-16 10:36:12 <ncopa> however, I usually build isos manually long before that for testing 
2024-04-16 10:37:27 <ncopa> not sure what release media makes most sense for loongarch64
2024-04-16 10:43:22 <huajingyun> So this means that after the main and community warehouse edge are built, you can start making the iso and then test it.
2024-04-16 10:43:41 <huajingyun> for loongarch64, I think we  try to refer to x86_64. At present, it is better to have alpine-standard iso.
2024-04-16 10:46:11 <mps> huajingyun: does loongarch64 use u-boot for booting
2024-04-16 10:47:46 <mps> I see references in u-boot git log
2024-04-16 10:50:30 <huajingyun> mps: we use uefi
2024-04-16 10:50:48 <mps> aha, thanks
2024-04-16 10:51:42 <huajingyun> you're welcome
2024-04-17 09:27:26 <huajingyun> hi, I may disable ocaml and related packages on loongarch64, just like riscv64, because ocaml are currently not supported by the upstream
2024-04-17 09:27:34 <huajingyun> this will involve the community and testing.
2024-04-17 10:16:09 <ncopa> yeah, thats a good idea
2024-04-17 12:45:42 <celie> OCaml 5 maintainer here (OCaml 4 is maintained by @omni), and i'm fine with this
2024-04-17 12:46:51 <celie> I saw the pull request at OCaml upstream where (from memory) they pretty much said they didn't have the resources to maintain Loongarch support in tree
2024-04-17 12:48:46 <celie> Do give me a ping if you all manage to work things out with OCaml upstream
2024-04-18 01:08:47 <huajingyun> Thanks.
2024-04-18 01:09:10 <huajingyun> celie: i will ping you when there is any progress on loongarch64 for OCaml 5
2024-04-18 01:10:57 <celie> huajingyun: Do you have any branch pushed for the OCaml APKBUILD changes?
2024-04-18 01:11:39 <celie> For disabling loongarch64 on them
2024-04-18 01:14:59 <celie> I was thinking of working on that myself, but thought of checking with you to avoid duplicated effort
2024-04-18 01:18:46 <huajingyun> oh, that's great! 
2024-04-18 01:19:26 <celie> So, i'll do it then?
2024-04-18 01:20:19 <huajingyun> yeah, thank you for completing it
2024-04-18 06:04:32 <cely> huajingyun: You might want to recheck what i've done. The majority of OCaml aports have been disabled. Together with !64427 and !64428 that should cover all of the aports using OCaml, with the exception of community/cloudi.
2024-04-18 06:05:09 <cely> As i am enabling arch="all" for libguestfs, i would also appreciate it if you tell me whether that works on loongarch64.
2024-04-18 06:06:08 <cely> That's why that MR is in draft, when i know whether to add !loongarch64 to testing/libguestfs (will be for some other reason now that OCaml is no longer used by that aport), i will take it out of draft.
2024-04-18 06:12:03 <cely> Ok, so the OCaml compiler is actually required for libguestfs..
2024-04-18 06:17:23 <cely> So, never mind about the libguestfs thing, that will also have to be disabled for loongarch64, sorry for the noise
2024-04-18 06:23:50 <huajingyun> cely: hi cely,  sorry i just saw your message
2024-04-18 06:23:58 <huajingyun> you are right, thank you for doing this for  loongarch64.
2024-04-18 06:29:05 <cely> You're welcome
2024-04-18 06:30:31 <cely> As Cloudi's APKBUILD involves multiple languages, i have notified the maintainer of Cloudi about this change (disabling loongarch64 due to no OCaml compiler support), and will let him decide what needs to be done.
2024-04-18 06:31:23 <cely> Maybe only the OCaml part needs to be disabled, and the other languages (like Erlang and Java) are working on Loongarch.
2024-04-18 06:32:29 <huajingyun> okay, thank you very much!
2024-04-18 06:33:21 <cely> You're welcome, that should cover all the aports using OCaml that i could find, if i've left out any, do let me know.
2024-04-18 06:35:51 <huajingyun> No problem, thanks!
2024-04-20 01:30:22 <cely> znley: Not sure if you check IRC on a weekend, but just wondering if you noticed the comment in ruby-net-smtp that says to keep its version in sync with "Bundled gems"?
2024-04-20 01:33:54 <znley> Yes, i saw it
2024-04-20 01:36:38 <znley> cely: I will check again, the main reason is that ssl test of the ruby-net-smtp old version will fail.
2024-04-20 01:38:50 <cely> Ok, i guess you have a reason to upgrade then, would be good if you mention that in the MR
2024-04-20 01:41:14 <znley> Yes, it’s strange why it failed. Could it be that the self-signed certificate has expired?
2024-04-20 01:42:54 <cely> Probably: https://github.com/ruby/net-smtp/pull/75
2024-04-20 01:43:13 <znley> https://github.com/ruby/net-smtp/blob/v0.4.0/test/net/fixtures/server.crt#L9
2024-04-20 01:44:27 <znley> It's indeed expired
2024-04-22 00:21:39 <celie> Looks like the maintainer of ruby-net-smtp has fixed the expired certs which caused tests to fail (!64622)
2024-04-22 11:28:22 <znley> Hi, I am debugging a memory allocation problem. I want to enter the musl library through gdb. I installed musl-dbg but still cannot enter. What may be the reason?
2024-04-22 11:32:44 <znley> celie: The fix for ruby-net-smtp is so good that I will close the upgrade later.
2024-04-23 03:01:30 <huajingyun> util-linux 2.40 seems to no longer provide col, apcupsd build fails due to missing col.
2024-04-23 03:07:14 <ikke> huajingyun: upstream added some conditional to only support it on glibc systems, mentioning it's deprecated anyway..
2024-04-23 03:07:39 <celie> I have !64687
2024-04-23 03:09:31 <huajingyun> That's good
2024-04-23 07:01:07 <celie> huajingyun: !64703 should fix the test issue you are seeing with libzip
2024-04-23 07:12:13 <huajingyun>  celie:  okay, sorry for not seeing it in time, I will close this MR.
2024-04-23 07:12:19 <huajingyun> Thanks
2024-04-23 07:24:02 <celie> You're welcome
2024-04-23 11:06:08 <celie> Hello, just wondering, has Rust been bootstrapped on loongarch64 musl?
2024-04-23 11:29:01 <huajingyun>  celie:  Yes, Rust has been built
2024-04-23 11:29:11 <huajingyun> I'm recently upgrading python3.12 for loongarch64 and rebuild aports edge, I will upload the packages to dev.a.o later
2024-04-23 12:37:25 <celie> Sorry, that question about Rust was my bouncer replaying old messages
2024-04-23 12:51:07 <huajingyun> It's okay.
2024-04-23 12:51:21 <huajingyun> I'm uploading the packages to https://dev.alpinelinux.org/~loongarch/edge/
2024-04-23 12:51:46 <huajingyun> This is the upgraded python3.12 and  built packages, which will be continuously updated with aports edge.
2024-04-23 13:06:44 <celie> That's great
2024-04-23 13:07:02 <celie> The community directory is empty though, i guess it hasn't uploaded yet
2024-04-23 13:25:30 <celie> By the way, regarding the Rust patches you submitted in !62982, you've mentioned that they will be included in Rust 1.78.0. Does that mean we won't need any more patches for Loongarch when Rust 1.78.0 is out?
2024-04-24 01:47:26 <huajingyun> celie: The community directory upload completed.
2024-04-24 01:47:44 <huajingyun> Regarding Rust patches, when upgrading to 1.78, I think we only need to consider the relevant patches in the vendor directory, which are libc, compiler-builtins and openssl-src
2024-04-24 01:47:54 <huajingyun> compiler-builtins 0.1.109 already supports loongarch64, which we will no longer need if it is included in rust 1.78
2024-04-24 01:48:23 <huajingyun> openssl-src: It is supported upstream at https://github.com/alexcrichton/openssl-src-rs/pull/234
2024-04-24 01:48:24 <huajingyun> libc: It is supported  https://github.com/rust-lang/libc/pull/3605
2024-04-24 01:48:57 <huajingyun> but there are no new releases of openssl-src and libc yet
2024-04-24 01:49:09 <huajingyun> maybe these small patches need to continue to exist for a short period of time.
2024-04-24 01:51:45 <cely> Alright, thanks for the info.
2024-04-24 02:00:43 <huajingyun> You're welcome
2024-04-24 02:06:51 <huajingyun> cely: as a digression, are you and celie the same maintainer? i'm just guessing:-D
2024-04-24 02:07:21 <cely> Yes, the same
2024-04-24 02:10:51 <huajingyun> Alright, thanks
2024-04-24 02:25:40 <cely> Just wondering, have you finished building community, or are you still working on that?
2024-04-24 02:38:06 <huajingyun> It’s not finished yet and is still being worked on.
2024-04-24 02:49:36 <cely> Ok
2024-04-24 03:38:46 <huajingyun> cely: Due to Luajit limitations, I have updated some related packages, all packages have no pkgrel bumps (  !64526 and  !64527 )
2024-04-24 03:39:07 <huajingyun> Can you help me review them? Thanks.
2024-04-24 03:45:40 <cely> I think maybe it would be better if they are reviewed by the luajit maintainer, but if the other developers think that it is also appropriate for me to review them, then i wouldn't mind.
2024-04-24 06:03:09 <huajingyun> Hmm, that's a good idea, I will ping the luajit maintainer first.
2024-04-24 06:03:14 <huajingyun> Thanks
2024-04-24 06:05:17 <huajingyun> It seems that reviewers will not be automatically assigned when an MR contains multiple package modifications.
2024-04-24 06:08:10 <cely> Yes, that's true, i may be wrong, but i don't think multiple people can be assigned to a specific MR, but i think you can put out review requests to multiple people
2024-04-24 06:10:07 <huajingyun> Ok, thank you
2024-04-24 06:50:49 <ikke> correct 
2024-04-28 06:29:45 <cely> huajingyun: Just wondering if you saw the Rust MR i requested a review on
2024-04-28 06:30:07 <cely> By the way, i see you're working on tpm2-tss-engine as well
2024-04-28 06:30:15 <cely> That is being discussed in !64820
2024-04-28 06:38:14 <huajingyun> Sorry, I didn't have time to check my email today, I just saw it reminding me in the email.
2024-04-28 06:38:15 <huajingyun> I'll take a look now
2024-04-28 06:38:39 <cely> No problem
2024-04-28 06:45:34 <huajingyun> cely: looks good
2024-04-28 06:45:34 <huajingyun> In order to be more accurate, I am going to compile it (!64977) on loongarch64 and verify.
2024-04-28 06:46:05 <cely> Sure, that's a good idea
2024-04-28 06:47:35 <huajingyun> yes, just wait a moment.
2024-04-28 10:55:03 <huajingyun> Hi cely，i updated the comment in !64977.
2024-04-28 10:55:14 <huajingyun> Thank you
2024-04-28 12:52:26 <cely> huajingyun: Thanks for the patch. I think i would like to see if i can solve this in another way, that is more specific to the alpine target, i'll see if i can push my changes today or tomorrow, and you can try to see if it works.
2024-04-28 12:57:48 <cely> After all it's the alpine target that enforces the use of LLVM17, and those features should continue to work for loongarch64-unknown-linux-musl with vendored LLVM18, so maybe reverting the commit is not really necessary.
2024-04-28 12:58:15 <cely> If you try it out, and my method doesn't work, then i'll use your patch.
2024-04-28 13:36:23 <cely> huajingyun: Alright, i've pushed my patch to !64977, please try it out when you find the time and let me know if the "not a recognized feature" log messages are still displayed.
2024-04-29 00:12:02 <celie> Anyway, if compiling Rust until the end takes a long time, then just compile until the point where the error messages start appearing
2024-04-29 00:13:09 <celie> According to the release schedule, a Rust 1.78.0 pre-release should come out later today, and i hope to update my MR if i am available then
2024-04-29 00:17:59 <celie> In the past, i have observed that the source tarball does not change between pre-release and release (which should happen later this week on 2nd May)
2024-04-29 00:21:56 <celie> So, maybe after backing up the .apk for Rust 1.77.0, if you wish, you can upgrade to the 1.78.0 pre-release, and use that to build some Rust aports, to find out if there are any other issues with the changes i made to the loongarch64 patches
2024-04-29 00:23:16 <celie> I will probably leave it up to the other members of team/rust to decide when Rust 1.78.0 actually gets in
2024-04-29 00:53:44 <huajingyun> celie:  thanks, now I will compile again with your new patch.
2024-04-29 00:53:55 <huajingyun> In addition, you mentioned using 1.78 to build Rust aports, which is exactly what I want to do.
2024-04-29 01:26:46 <huajingyun> celie:  Rust compilation is not completely finished yet
2024-04-29 01:26:51 <huajingyun>  However, logs about "not a recognized feature" still appeared during the compilation process. 
2024-04-29 02:05:56 <cely> Ok
2024-04-29 02:06:14 <cely> I will apply your patch then
2024-04-29 02:11:50 <huajingyun> Thank you !
2024-04-29 02:13:47 <cely> You're welcome
2024-04-29 02:14:13 <cely> Ok, updated the MR, and i also renumbered the patches
2024-04-29 02:16:01 <huajingyun> Oh, that's great.
2024-04-29 15:37:46 <celie> huajingyun: i have updated my MR to the pre-release, which usually has the same tarball as the release itself, so if you want to start building Rust aports with Rust 1.78, you can probably start with the pre-release
2024-04-30 03:24:42 <huajingyun> cely:  ok i see it, i will make time to do it
2024-04-30 03:24:48 <huajingyun> Thanks