2024-06-01 13:36:04 Hmm, now J0WI is merging lots of MRs, and insisting on pkgrel bumps, i wonder if it's really necessary to rebuild all those aports (and i think most of them are written in Rust, so will take some time to rebuild all of that) 2024-06-01 13:50:28 ACTION counts..J0WI has requested pkgrel bumps on 34 aports 2024-06-01 14:12:00 It seems J0WI has opened !67046 now with 19 aports, i think the ones they merged before realizing that pkgrel wasn't bumped 2024-06-01 14:13:25 I'll be interested to know if alpine/aports's 6-hour CI limit will be enough to rebuild all those 19 aports 2024-06-01 14:15:21 It doesn't help that most of those aports were the ones where maintainers did not respond (i think most of those where approval was given have already been merged) 2024-06-01 14:16:28 which begs the question, if those aports encounter failures on other archs, who's going to fix them 2024-06-01 14:16:56 I think most of those in community/ should be safe, as they were rebuilt for 3.20, so probably won't run into issues 2024-06-01 14:18:35 If they fail to build and are unmaintained, we should either remove them or find a new maintainer 2024-06-01 14:18:38 especially if it's in testing 2024-06-01 14:18:57 But I think we also need to think about a strategy regarding the number of MRs 2024-06-01 14:19:08 and also the number of rebuilds now 2024-06-01 14:19:12 as most of them are Rust 2024-06-01 14:19:26 pkgrel bumps do not affect CI though 2024-06-01 14:19:41 They are built whether pkgrel is bumped or not 2024-06-01 14:20:05 Yes, but edge will be blocked while processing this big backlog of MRs 2024-06-01 14:23:16 I sort of remember though, will have to check the logs on irclogs.a.o, that the idea of adding support for Loongarch to aports in bulk was proposed first 2024-06-01 14:23:34 I think certain kinds of changes can be done in bulk 2024-06-01 14:23:49 for rv64, most changes were done in bulk 2024-06-01 14:23:55 Not individual MRs 2024-06-01 14:24:15 and then it was thought that having individual MRs would be better for review, but we've now hit the maintainer-no-response problem 2024-06-01 14:25:02 Well, it's a problem that already exists, just made more visible 2024-06-01 14:25:38 I guess that's true 2024-06-01 14:29:55 Maybe we should add something akin to update_config_sub() for bumping Rust's libc crate to abuild, and then just do such a change in bulk 2024-06-01 14:30:26 That doesn't really address the issue of whether a pkgrel bump is needed though (i think for update_config_sub, most of the time, pkgrel is not bumped) 2024-06-01 14:31:04 usually that change will not affect other arches though, while bumping the libc crate can 2024-06-01 14:31:39 Not sure if adding that to abuild would then mean abuild needs to depend on cargo though 2024-06-01 14:35:27 or maybe such a change can be done through the usual shell tools, as it is usually just looking for `name = "libc"` and then replacing version= and checksum=, would still need a way of getting the checksum though 2024-06-01 14:35:55 the new checksum* 2024-06-01 14:56:17 I think the effects of handling so many MRs have started to appear..J0WI has mislabelled a few upgrades with arch:loongarch64 and aports:add 2024-06-02 02:11:32 I gave it some thought, and (1) Rust aports in testing is a blind spot because we don't rebuild them, unlike Go/Python that we do rebuild, and unlike aports in main and community which get rebuilt for stable branches 2024-06-02 02:14:13 (2) making pkgrel bumps mandatory introduces a subtle shift in assumptions, from "this works on Loongarch" to "this works on all archs". see the example of cargo-crev, that was bumped only to fail on 32-bit due to p384 (which was worked around), and then failed due to something else on armhf (and so it ended up getting disabled) 2024-06-02 02:27:03 So, if pkgrel bumps are going to be required for things like libc crate updates, maybe it would be better to just stop patching Rust aports for the time being, perhaps except for aports that (i) Loongarch wishes to showcase as an example of something that works on this arch 2024-06-02 02:32:13 or (ii) an aport that the Loongarch team members have an interest in, which means also ensuring that the aport works on all other archs besides Loongarch (i'm not sure about other developers, but most of the time when an MR involves Loongarch, i have not bother so much about the other archs 2024-06-02 02:35:24 making pkgrel bumps mandatory will change that, however. i think we want to avoid a repeat of a similar scenario like what happened with cargo-crev, and as pkgrel bumps are already requested for 30 or so other aports, very likely a few of them will fail on other archs) 2024-06-02 02:35:44 s/bother/bothered/ 2024-06-02 02:40:33 It would be alright if, when that happens, the aport maintainer steps in to fix the aport for the other failing arch, but unfortunately, i don't think that happens often (while Loongarch is willing to patch Rust aports, i don't think Alpine maintainers can keep up) 2024-06-02 02:51:08 So, so sum it up, what i'm proposing is, for the time being, Rust aports that require patches (and so pkgrel bumps) instead get disabled with a !loongarch64, with probably some rare exceptions being made for some aports 2024-06-02 02:55:09 and this can be reconsidered after (a) we clear the backlog of all the MRs that now require pkgrel bumps, and (b) maintainers get more involved in helping to solve issues on other archs uncovered by those pkgrel bumps 2024-06-02 03:10:57 s/so sum/to sum/ 2024-06-02 05:06:31 celie: what I'm wondering about is why it succeeded in CI 2024-06-02 05:08:25 Did it? 2024-06-02 05:09:02 CI was even before p384 was worked around 2024-06-02 05:09:12 So, it should've failed for all three 32-bit archs 2024-06-02 05:12:42 It didn't succeed: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/66533/pipelines 2024-06-02 05:13:39 I think this is exactly the kind of situation we want to avoid 2024-06-02 05:14:01 Where CI fails for archs other than Loongarch, and the maintainer does not participate in fixing them 2024-06-02 05:14:23 Unless Loongarch team members are expected to solve the issues with other archs too 2024-06-02 05:15:06 (which is why i listed aports that they have an interest in (and are able to work on issues with other archs, should the need arise) as a potential exception) 2024-06-02 05:15:36 I think J0WI was just happy to find an MR where pkgrel was bumped 2024-06-02 05:21:09 Besides that, lnl (@selfisekai) isn't an inactive maintainer, which is why i didn't merge my cargo-crev upgrade MR (in which the armhf CI succeeds), as there was already a previous one that she did not give a LGTM to 2024-06-02 05:21:44 (no idea why, perhaps there's something in the newer versions she wants to look deeper into before giving LGTM) 2024-06-02 05:28:30 For the aports in main/ and community/, and the Go/Python aports in testing/, we roughly know which ones are expected to be green in CI (as they are all regularly/occasionally rebuilt) 2024-06-02 05:28:36 but Rust aports in testing/ are a big blind spot 2024-06-02 05:29:16 and actually, maybe some of the Rust aports in main/ and community/ too, because Rust was upgraded halfway through 3.20 (when many archs had already built Rust aports with the previous Rust) 2024-06-02 05:30:23 So, we don't really know which ones are going to suddenly run into problems on other archs 2024-06-02 05:35:48 and as the number of pending MRs increase, accidents like cargo-crev are likely going to happen (if a pkgrel bump was not required, then it would be fine if the Loongarch MRs only took care of Loongarch, but i think we are now going in the direction of wanting pkgrel bumps) 2024-06-02 05:48:04 so it was merged even though CI failed 2024-06-02 05:49:42 Yes, that seems to be what happened 2024-06-02 05:49:58 That's the issue then 2024-06-02 05:51:11 An additional consideration is that, if the maintainer does not participate in fixing the other failing archs, then it will just become another MR in the long list of unmergeable MRs 2024-06-02 05:51:35 yes 2024-06-02 05:52:12 which i assume will then block that aport on Loongarch (as the fix in contained in the same MR that discovered other failing archs) 2024-06-02 05:52:19 the Loongarch fix* 2024-06-02 05:52:30 So, maybe it would be better to just disable Loongarch in that case 2024-06-02 05:52:34 Wouldn't the same issue affect loongarch as well 2024-06-02 05:52:36 ? 2024-06-02 05:52:54 No, the cargo-crev issue was 32-bit specific, as far as i know 2024-06-02 05:52:56 right 2024-06-02 05:53:38 and i assume that if Loongarch team members open MRs with fixes for Loongarch, then they know the changes they propose will allow the aport to build on Loongarch 2024-06-02 05:53:48 Another solution is to disable it on 32-bits arches 2024-06-02 05:53:52 if it fails there 2024-06-02 05:53:59 Hehe 2024-06-02 05:54:02 and no one wants to fix it 2024-06-02 05:54:20 We do that all the time 2024-06-02 05:55:46 and also: reconsider rebuilding rust packages 2024-06-02 05:56:15 Well hopefully it is as you say, that most of the issues affecting other archs can be fixed together with the patch for Loongarch 2024-06-02 05:56:52 Maybe we can consider rebuilding Rust aports when we know how long that will take 2024-06-02 05:57:08 I think Go rebuilds usually finish in a day or two 2024-06-02 05:57:14 but i don't expect that to be the same for Rust 2024-06-02 05:58:34 If it takes a week or so, and no one fixes the build failures as they arise, then rebuild Rust aports will just be a big builder blocker 2024-06-02 05:58:42 Unless you are talking about rebuilding them in CI 2024-06-02 05:59:19 But that would probably require a huge CI timeout 2024-06-02 05:59:34 Can be done in phases 2024-06-02 06:00:31 Then it will probably have to be carefully planned so it completes before Rust upstream releases the next version 2024-06-02 06:01:27 Would be cool to be able to have a low priority ci queue 2024-06-02 06:02:32 an idea i had was to open the Rust rebuild MRs in an aports fork under team/rust 2024-06-02 06:02:51 So there is less noise in alpine/aports 2024-06-02 06:03:28 You'd still compete for CI resources 2024-06-02 06:05:50 Yeah, that's a concern, but i think if rebuilding Rust aports does become a regular thing, we wouldn't want a few MRs for that (if done in phases) in alpine/aports every 1.5 months (which is the Rust release cycle, afaik) 2024-06-02 06:08:12 Amount of aports depending on rust/cargo increased a lot 2024-06-02 06:09:42 Yea, not sure if i should be happy or sad about that.. 2024-06-02 06:35:43 If only rust wasn't so slow to build packages 2024-06-02 06:37:27 :( 2024-06-02 07:16:11 Ah, a trip down memory lane: https://pcwalton.blogspot.com/2011/04/road-ahead-for-rust.html 2024-06-02 07:16:30 "Compiler performance. Currently, it takes 15 minutes on an Opteron for rustc to compile itself. That's far too slow to be practical." 2024-06-02 07:50:26 maybe it is also worth considering again to package rust dependencies, so that they won't rebuild all the time. not sure if that works tho 2024-06-02 07:59:30 You mean let them be dynamically linked? 2024-06-02 08:41:52 yes 2024-06-03 01:56:35 Hi, all, thanks for your discussion. 2024-06-03 01:56:44 my current idea is this: 2024-06-03 01:56:44 1. For rust libc related packages that have not created MRs, we may be able to disable them in batches on loongarch64, and then our team will submit these changes to the upstream of the project at the same time. When the upstream is merged and released, we only need to upgrade in aports. 2024-06-03 01:56:44 This is just a matter of time. Before that, maintainers don't have to worry about fixing errors in other architectures. 2024-06-03 01:56:44 This can reduce most of the uncertainty of building on other architectures. 2024-06-03 01:56:44 Of course, if we find that individual packages are necessary during the process of building aports on loongarch64, we will reopen them. 2024-06-03 01:57:15 2. For MRs (rust libc) that have been created, currently J0WI requires bumps pkgrel MRs, do we need to bump pkgrel for them? we have submitted most of these changes to the upstream of the project, and many of them have been merged. 2024-06-03 02:17:45 Regarding (1), i think that is good, using an upgrade to enable Loongarch will also avoid problems on other archs that have already been fixed in the upgrade 2024-06-03 02:18:59 which is the situation with cargo-crev, latest version has libc 0.2.155 that Loongarch requires, and works on 32-bit ARM 2024-06-03 02:21:45 Yes, we should prioritize ensuring that the upstream libc of the project is reliable for loongarch64, which can fundamentally solve the problem. 2024-06-03 02:26:12 It still doesn't solve the maintainer-no-response problem though, if a maintainer doesn't respond to a (simpler, in my opinion) libc crate update, very likely they won't respond the an upgrade either 2024-06-03 02:27:05 A while ago, i had the idea that maybe some of the Loongarch team members would be interested in taking up maintainership for some of those aports, but not sure how appropriate that would be 2024-06-03 02:32:27 Golang aports(golang.org/x/sys) has the same problem. Maybe we can disable some inactive packages for a long time. Mainly maintain those active packages. 2024-06-03 02:32:41 Regarding (2), i have some concerns about that (a) bumping pkgrel for 34 aports would mean CI will be occupied for a while, and (b) since J0WI requested the pkgrel bump, does that mean they will take care of merging the MRs (despite lack of maintainer response) once pkgrel is bumped 2024-06-03 02:33:57 Golang aports are bumped very often when Go itself is upgraded, so we already roughly know the status of those aports on other archs (they should work) 2024-06-03 02:34:30 and Go is also much faster at compiling compared to Rust :) 2024-06-03 02:38:01 cely: Do you mean we can have the right to merge MR and can maintain them? If we can do that, that would be great 2024-06-03 02:38:10 it would be best to organize a package list 2024-06-03 02:38:49 Not sure how many packages need to maintain 2024-06-03 02:45:35 Umm, not really for the merge MR part 2024-06-03 02:45:57 Maintainers do not have that ability 2024-06-03 02:47:20 but in general, MRs opened by maintainers of aports are merged, especially if they're just upgrades 2024-06-03 02:48:47 For non-maintainer upgrades, some developers will merge them after waiting for a while, but some are more careful, and will continue to wait for maintainer approval 2024-06-03 02:49:25 which is why so many non-maintainer MRs just sit there 2024-06-03 02:52:08 and maintainer can review MR and submit comments or something like "LGTM" 2024-06-03 02:52:38 but if you can put together a list, maybe we can ask N Copa when he comes back, and decide which ones can have maintainership transferred 2024-06-03 02:53:10 You should avoid adding to the list aports by maintainers that are still active in Gitlab though 2024-06-03 02:53:34 Some maintainers are still active, but just don't look at MRs assigned to them that often 2024-06-03 02:55:57 I might look for it from the packages that have been submitted MRs and have not been responded to for a long time. 2024-06-03 02:56:07 Maybe the "author" search at https://git.alpinelinux.org/aports/ can help, i think anything with a maintainer that has not been seen for 3 years can be considered 2024-06-03 02:56:26 especially for aports in testing 2024-06-03 02:57:35 OK, I'll make time to check it out. 2024-06-03 02:57:55 Well yeah, i think at this point i have to mention some names now (sorry to those watching the log), i have been trying to avoid this for some time 2024-06-03 02:57:56 When will N Copa come back? 2024-06-03 02:58:29 but here goes, i think you should not ask for aports maintained by @jirutka, @mpolanski, or @omni even though they have not responded to MRs 2024-06-03 02:58:41 They are developers, and still active 2024-06-03 02:58:46 though a bit busy lately, it seems 2024-06-03 02:59:32 I'm not really sure, he mentioned that he would be away for a week or two 2024-06-03 02:59:39 I think we're at a week now 2024-06-03 03:01:17 OK, I've noticed the three developers you mentioned before, and I'll avoid their aports 2024-06-03 03:06:07 Just mentioned the MRs that J0WI requested the pkgrel bump. I may need to ask the team members to handle it. Maybe JOMI will merge them later. 2024-06-03 03:08:26 Sure, but if possible, try not to do that all at once, as it will hold up CI (and by the way, i think clicking "Rebase without pipeline" does not stop an already running CI pipeline) 2024-06-03 03:09:42 I've noticed that sometimes you all click "Rebase without pipeline", but i think that should be avoided now (as it doesn't cancel the already running pipeline, and also makes it harder for us to see which MRs have CI that succeeded) 2024-06-03 03:10:25 Developers will rebase when they are going to merge the MR 2024-06-03 03:12:14 OK,get what you mean,thank you. 2024-06-03 03:12:30 You're welcome 2024-06-03 05:54:46 I'm working on making CI for !67109 green, sadly based on https://git.alpinelinux.org/aports/log/testing/jami-daemon this is one of the aports where the maintainer added it and then never touched it again 2024-06-03 09:14:28 huajingyun: about that, most of them don't really need a pkgrel bump 2024-06-03 09:15:42 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/66003#note_410215 2024-06-03 09:19:47 That's the thing, i don't think we really have the criteria for when a pkgrel bump is needed written down 2024-06-03 09:19:55 So, it'll be developers contradicting each other 2024-06-03 09:25:05 znley: For !67124, maybe you could try replacing the autosetup/autosetup-config.{guess,sub} files? 2024-06-03 09:25:41 update_config_guess/sub does that automatically, but in this case the files don't have their standard names 2024-06-03 09:37:48 I hope so too, it would be best if J0WI agrees to do so 2024-06-03 09:43:08 J0WI has also started !67046, which i assume will be merged once the issues found by CI are resolved 2024-06-03 09:48:14 Oh, I see, let's wait. 2024-06-03 11:15:02 cely: Ok, I actually did it the way your said on others packages(cp "$sharedir/config.{sub/guess}" to ). I'm just not sure which one is better, this or disable. 2024-06-03 11:58:10 If copying config.{sub,guess} over to autosetup/ works, then maybe this will be better 2024-06-03 12:00:03 I get it. 2024-06-03 13:36:35 I think you forgot to remove fix-gvisor.patch in !67138 2024-06-04 00:46:57 cely: yes, thanks 2024-06-04 00:54:27 There's also a question that's been asked in !67122 2024-06-04 01:04:05 it seems Clayton doesn't know update_config_sub, we will reply 2024-06-04 06:52:55 Hi,all 2024-06-04 06:53:06 I want to try to setup a build-edge-loongarch64 locally using lxc, just like other architectures in alpine (build.alpinelinux.org), how should I do it, any suggestions? 2024-06-04 07:03:18 I'm trying to use aports-build 2024-06-04 07:07:14 I'm afraid i can't help you with that, but just curious, how were you building aports before (the ones that you've uploaded to dev.alpinelinux.org)? 2024-06-04 07:16:25 I mean, just wondering if you were building them manually (running `abuild` in a clone of aports) 2024-06-04 07:16:43 I currently use the buildrepo tool to continuously build aports edge, and then rsync these packages to dev.a.o 2024-06-04 07:16:54 I believe there is a better automated way in alpine, maybe it is aports-build, I am trying it. 2024-06-04 07:17:23 I may have found something 2024-06-04 07:17:53 https://wiki.alpinelinux.org/wiki/User:Ncopa/buildserver 2024-06-04 07:18:13 I guess that's some notes N Copa wrote up 10 years ago 2024-06-04 07:18:17 Not sure if it still works 2024-06-04 07:19:55 Yes, for all packages that need fixes on loongarch64 we use abuild to build and verify those changes. 2024-06-04 07:20:58 huajingyun: the builders use mqtt-exec to trigger aports-build 2024-06-04 07:24:28 Thanks, I'm taking a look 2024-06-04 12:51:41 Just wondering how using mqtt-exec/aports-build went 2024-06-04 14:24:42 huajingyun: When you find some time, could you try out !66627 on Loongarch again? Thanks 2024-06-04 14:25:01 I'm now preparing for Rust 1.79.0 which is due in about 10 days 2024-06-04 14:25:22 and have modified the Loongarch patches to apply on the latest beta (beta 8) 2024-06-04 14:25:53 I will re-number them once you confirm that it works 2024-06-04 14:26:56 LLVM18 will have to wait, unfortunately, due to issues on x86_64 and s390x 2024-06-04 14:28:40 So, the 0007 revert frecipe and relax patch has been modified too, i wasn't sure how to adapt some of the files under tests/ui, so i've just removed them from the patch as we aren't running those tests anyway 2024-06-04 14:30:01 If you think those files under tests/ui should still be included in 0007, then please give me an updated version of that patch 2024-06-04 14:30:59 Overall, i think the number of patches in main/rust needed for Loongarch is getting smaller for each Rust release 2024-06-04 14:31:27 Though i have no idea why this beta has 3 versions of libc, so that patch needs to be repeated 3 times :/ 2024-06-04 14:31:42 I don't expect that to change for the actual 1.79.0 release though 2024-06-04 14:33:05 So, hopefully 1.80.0 will lower down the number of libc versions included, and even better, if it just uses 0.2.154 or 0.2.155 which won't require patching for Loongarch 2024-06-04 17:13:59 Only tangentially related (because we discussed pkgrel bumps), but more MRs with pkgrel bumps that may not be needed: !67198 !67205 2024-06-04 17:15:15 Maybe if the commit message read "rebuild" it would be reasonable, but in this case it says something else, which imo, does not warrant a pkgrel bump 2024-06-04 18:56:01 and yet more advice to bump pkgrel! !66881 2024-06-04 18:56:17 We really need something written up on when to bump pkgrel 2024-06-04 18:56:59 (by the way, do not follow that advice, bumping pkgrel is not needed to disable loongarch64) 2024-06-04 18:57:37 ACTION goes AFK 2024-06-05 00:47:30 For !66877, if Loongarch is disabled, why does the libc crate still need to be updated? 2024-06-05 00:47:34 (2) making pkgrel bumps mandatory introduces a subtle shift in assumptions, from "this works on Loongarch" to "this works on all archs". see the example of cargo-crev, that was bumped only to fail on 32-bit due to p384 (which was worked around), and then failed due to something else on armhf (and so it ended up getting disabled) 2024-06-05 00:47:34 I gave it some thought, and (1) Rust aports in testing is a blind spot because we don't rebuild them, unlike Go/Python that we do rebuild, and unlike aports in main and community which get rebuilt for stable branches 2024-06-05 00:47:36 So, if pkgrel bumps are going to be required for things like libc crate updates, maybe it would be better to just stop patching Rust aports for the time being, perhaps except for aports that (i) Loongarch wishes to showcase as an example of something that works on this arch 2024-06-05 00:47:38 or (ii) an aport that the Loongarch team members have an interest in, which means also ensuring that the aport works on all other archs besides Loongarch (i'm not sure about other developers, but most of the time when an MR involves Loongarch, i have not bother so much about the other archs 2024-06-05 00:47:38 making pkgrel bumps mandatory will change that, however. i think we want to avoid a repeat of a similar scenario like what happened with cargo-crev, and as pkgrel bumps are already requested for 30 or so other aports, very likely a few of them will fail on other archs) 2024-06-05 00:47:40 It would be alright if, when that happens, the aport maintainer steps in to fix the aport for the other failing arch, but unfortunately, i don't think that happens often (while Loongarch is willing to patch Rust aports, i don't think Alpine maintainers can keep up) 2024-06-05 00:47:40 s/bother/bothered/ 2024-06-05 00:47:42 So, so sum it up, what i'm proposing is, for the time being, Rust aports that require patches (and so pkgrel bumps) instead get disabled with a !loongarch64, with probably some rare exceptions being made for some aports 2024-06-05 00:47:42 and this can be reconsidered after (a) we clear the backlog of all the MRs that now require pkgrel bumps, and (b) maintainers get more involved in helping to solve issues on other archs uncovered by those pkgrel bumps 2024-06-05 00:47:44 s/so sum/to sum/ 2024-06-05 00:48:47 There's also a question that's been asked in !67122 2024-06-05 00:49:14 Maybe if the commit message read "rebuild" it would be reasonable, but in this case it says something else, which imo, does not warrant a pkgrel bump 2024-06-05 00:49:14 Only tangentially related (because we discussed pkgrel bumps), but more MRs with pkgrel bumps that may not be needed: !67198 !67205 2024-06-05 00:49:16 and yet more advice to bump pkgrel! !66881 2024-06-05 00:49:16 We really need something written up on when to bump pkgrel 2024-06-05 00:49:18 (by the way, do not follow that advice, bumping pkgrel is not needed to disable loongarch64) 2024-06-05 00:49:18 ACTION goes AFK 2024-06-05 01:27:29 Very comprehensive consideration, this is what I personally agree with. This will not affect the existing alpine system and it can make subsequent work more flexible. 2024-06-05 01:28:23 cely: No problem, I'll verify it again !66627, maybe later today, and I'll let you know here when it's done 2024-06-05 01:28:40 We have a consensus on Rust libc related aports. I think what we will do next is: 2024-06-05 01:28:40 (1) Update the currently unmerged Rust libc related MRs (required to bump pkgrel) to !loongarch64 2024-06-05 01:28:40 (2) Disable uncommitted Rust related aports first 2024-06-05 01:28:40 For individual indispensable packages, we make exceptions 2024-06-05 01:38:03 So, my silly bouncer started replaying old messages again :( 2024-06-05 01:54:38 I just created !67218 for LLVM17, which fixes the error caused by it 2024-06-05 03:51:22 Just wondering, so Zewei also opens MRs for commits authored by Weijie? Does that mean there are 6 people working on the Loongarch port, though only 5 have Gitlab accounts to open MRs? 2024-06-05 06:02:14 cely: Oh, yes, sorry I didn’t explain it clearly before, Zewei and Weijie share a Gitlab account, so we are 6 people now 2024-06-05 06:05:13 Hehe, ok :) 2024-06-05 06:18:42 !66627 works fine on loongarch64. 2024-06-05 06:18:45 alpine:~/Celeste/aports$ rustc -Vv 2024-06-05 06:18:45 rustc 1.79.0 (d0f44a4cf 2024-06-03) (Alpine Linux 1.79.0-r0) 2024-06-05 06:18:45 commit-date: 2024-06-03 2024-06-05 06:18:45 commit-hash: d0f44a4cf3d25688be1f6dc4d67eabbbbca25609 2024-06-05 06:18:45 binary: rustc 2024-06-05 06:18:45 host: loongarch64-alpine-linux-musl 2024-06-05 06:18:47 release: 1.79.0 2024-06-05 06:18:47 LLVM version: 17.0.6 2024-06-05 06:19:16 cely: Regarding 0007 patch, you can use the one you have modified 2024-06-05 06:19:18 Thanks. 2024-06-05 06:20:48 You're welcome 2024-06-05 06:21:18 How's the mqtt-exec/aports-build thing going along? 2024-06-05 06:35:29 The address you shared is very useful to me, although some steps are invalid, probably because it is too long ago. 2024-06-05 06:35:29 But it doesn't seem difficult in fact. I setup them on my another dev machine and aports-build works. 2024-06-05 06:35:40 I need to sort out some more details before asking you. 2024-06-05 06:37:30 Actually, i don't know anything about setting up builders :) 2024-06-05 06:40:48 ikke and ncopa might be better at this 2024-06-05 06:48:09 Ah, i finally found the file where all the magic happens: main/aports-build/mqtt-exec.aports-build.confd 2024-06-05 06:48:55 Yes 2024-06-05 06:49:44 Ah, and the source of aports-build itself is stored in aports 2024-06-05 06:51:01 Yup 2024-06-05 06:54:22 Just wondering, what does msg.a.o run? 2024-06-05 06:54:51 Oh, probably mosquitto 2024-06-05 06:55:17 Indeed 2024-06-05 06:55:43 Found that by grepping for MQTT aports in main/ 2024-06-05 07:02:43 Hmm, it seems a password is only needed to publish build failures (i guess those are the messages algitbot relays to #alpine-commits)? 2024-06-05 07:13:39 I guess what i'm getting at is, while i see options to use TLS in the mqtt-exec source, i don't see any of the files in aports-build mentioning that, so wouldn't that mean passwords are sent in the clear? 2024-06-05 13:08:59 So, as i was saying in #alpine-devel 2024-06-05 13:09:08 I see some aports are disabled due to the "nix" crate 2024-06-05 13:09:52 Is there any way to determine which aports are affected? Maybe by looking at the version of the "nix" crate? 2024-06-05 13:11:33 or (i suspect) maybe it is "nix" in combination with a certain version of "libc"? 2024-06-05 13:19:02 I guess to put it in another (more specific) way, if "libc" is already at version 0.2.155 (an example would be qaqland's !67083), does "nix" 0.26.4 still give problems? 2024-06-05 13:20:08 Taking an example from my aport, community/halloy has libc 0.2.153 and nix 0.26.4 (also nix 0.28.0) 2024-06-05 13:21:03 and the reason for disabling Loongarch given in halloy's APKBUILD is due to "nix", so i'm wondering if maybe the reason is "libc" instead 2024-06-05 13:55:52 Hi mio 2024-06-05 13:56:15 cely: hi ^^ is it allowed to lurk here? 2024-06-05 13:56:36 hope you're having a good day ^^ 2024-06-05 13:56:46 Sure why not, this isn't exactly a private channel, it's already being logged at irclogs.a.o 2024-06-05 13:57:42 okay, thanks ^^ the nicklist is a bit shorter than -devel, just checking 2024-06-05 13:58:32 thought it might be easier to check here for loongarch-related MRs/questions 2024-06-05 14:00:04 e.g. status of loongarch builders, any action required for loongarch on next abump of existing packages 2024-06-05 14:00:24 :) 2024-06-05 14:01:19 ^^ 2024-06-06 01:17:48 cely: usually we upgraded libc, but the nix upgrade failed and caused the package to fail to build, then we rolled back the patch and marked the reason as nix, so more only the final blocking items were marked. 2024-06-06 01:18:41 When we encounter this situation again, should we mark whether it is libc or nix, or both? 2024-06-06 01:23:28 So, nix also needs an upgrade to be compatible with Loongarch? 2024-06-06 01:45:18 The upstream has already supported it (the latest is 0.29.0). When we want to upgrade for nix, it fails because there are multiple nix versions in the project. 2024-06-06 01:46:34 Yeah, that's a bit of a problem 2024-06-06 01:47:03 For example, the following error: 2024-06-06 01:47:03 nix@0.24.2 2024-06-06 01:47:03 error: There are multiple `nix` packages in your project, and the specification `nix` is ambiguous. 2024-06-06 01:47:03 Please re-run this command with one of the following specifications: 2024-06-06 01:47:03 nix@0.23.1 2024-06-06 01:48:22 i think that means you must use -p nix@0.23.1 and -p nix@0.24.2 2024-06-06 01:48:36 but probably you'll then run into other errors 2024-06-06 01:51:08 Yes, we tried, it doesn't work 2024-06-06 01:52:08 Anyway, thanks for the information 2024-06-06 01:53:00 How's the mqtt-exec/aports-build thing coming along? 2024-06-06 02:07:00 a little busy,I hope have time to set it up again today 2024-06-06 02:27:40 Sure, just curious, no hurry regarding that 2024-06-06 02:35:00 ok :) 2024-06-06 03:47:46 By the way, when you find some time, maybe you can look at !67083 and suggest what needs to be done to make it compatible with Loongarch 2024-06-06 03:47:54 It uses nix 0.26.4 2024-06-06 03:49:47 and i told qaqland i would look into the MR when Loongarch compatibility is sorted out (i'm trying to avoid having to look at a follow-up MR later on :)) 2024-06-06 06:04:22 Ok, I'll take the time to take a look and add an additional comment. 2024-06-06 06:06:46 Thanks 2024-06-06 06:11:33 You're welcome 2024-06-06 11:38:38 Can someone take a look at this mr !63807? No response for a long time. 2024-06-06 12:17:49 sure, taking a loog now 2024-06-06 12:17:52 look* 2024-06-06 12:19:13 merged :) 2024-06-06 12:33:40 Thanks. 2024-06-06 13:04:30 :-D 2024-06-07 01:40:44 So, J0WI has replied to !67046 2024-06-07 01:43:05 I think that's why, for me, at least, i will probably want to check whether new Go/Rust aports are compatible with Loongarch 2024-06-07 01:43:59 Otherwise, we could be looking at 3 MRs: 1 for adding the new aport, 1 for updating Cargo.lock or go.mod/sum, and 1 for the pkgrel 2024-06-07 01:44:10 bump 2024-06-07 01:50:36 what's the current procedure for new aports that pull in rust/cargo? do maintainers ask someone here with hardware access to test and then update the MR to disable if needed? 2024-06-07 01:50:59 Actually, there is no current procedure :) 2024-06-07 01:51:18 (if MR author updates the MR that is based on test results) 2024-06-07 01:51:36 okay ^^" 2024-06-07 01:52:43 e.g. for task3, bumped up rust/libc in Cargo.lock to the version that has loongarch support, but can't test if that actually builds (and runs) in loongarch hardware 2024-06-07 01:52:49 and we were actually looking at 3 MRs for some aports, before i suggested that for Rust aports, they could be temporarily disabled, and the Cargo.lock update submitted upstream 2024-06-07 01:53:05 which brought it down to 2 MRs 2024-06-07 01:54:07 okay, make sense to update it upstream 2024-06-07 01:54:17 You can always ask for it to be tried out here 2024-06-07 01:54:59 great, thanks, will keep that in mind ^^ 2024-06-07 01:55:58 You're welcome 2024-06-07 02:00:52 Yes, if there are new aports that need to be verified, you can tell us here 2024-06-07 02:00:57 Once loongarch64 CI is online, there will be no need for manual verification, which will make things simpler. 2024-06-07 02:02:40 thanks in advance, might eventually have questions for you and the team 2024-06-07 02:03:48 not sure if/when task3 package will go in, maybe the new CI will be up by then 2024-06-07 02:05:34 just keeping the arrangement in mind for next package bumps, so one less MR 2024-06-07 02:10:51 OK, I will find time to verify it today, including the pfetch-rs that cely mentioned yesterday 2024-06-07 02:16:37 and now for more Rust (crate/upstream) funny decisions: it seems latest rustls now uses AWS-LC instead of Ring (it was not too long ago that we got Ring into shape so it could be enabled for all archs) 2024-06-07 02:18:15 Ok, that's by default 2024-06-07 02:19:45 and Ring is still available, but that will likely mean we need to patch Rust aports to use this 2024-06-07 02:24:42 I've already seen that in one of my aports, and the switch to AWS-LC required adding to makedepends: cmake, (samurai), clang17-libclang, rust-bindgen, (and potentially, nasm) :/ 2024-06-07 02:24:56 Whatever 2024-06-07 02:26:23 (yes, it is trying to build some vendored code, not sure if we are able to add it as a separate aport to prevent that) 2024-06-07 02:27:44 Oh, and rust-bindgen didn't seem to be needed for 32-bit archs, but i didn't want to deal with adding a conditional makedepends 2024-06-07 05:55:23 !67306 !67309 !67312 's format warning could be fix easily 2024-06-07 06:29:52 qaqland: okay, thank you 2024-06-07 06:31:45 mio: task3 build pass on loongarch64, no additional patches are required. 2024-06-07 06:58:33 cely: pfetch-rs passed too. 2024-06-07 07:03:19 thanks 2024-06-07 07:39:12 So, pfetch-rs passed with nix 0.26.4, i wonder if that means pfetch-rs doesn't use the parts of nix that causes compatibility issues, or if nix 0.26.4 in combination with libc 0.2.155 is good enough for compatibility (and nix doesn't need to be updated to the latest) 2024-06-07 08:08:10 It' possible that pfetch-rs does not use the parts(iotcl) of nix. 2024-06-07 08:10:36 Ok 2024-06-07 08:14:17 nix merge loongarch64&riscv64 support on https://github.com/nix-rust/nix/pull/2045/files, but the content of this commit is disappared, I am also confused. 2024-06-07 08:16:09 Let us ask the developer who initiated the PR what happened. 2024-06-07 08:17:07 So, the commit contained more than the addition of 1 line? 2024-06-07 08:18:05 Here’s why: https://github.com/nix-rust/nix/commit/0e0e181d96db5b89e78c202b4ae9fdffdec7f31a 2024-06-07 08:20:31 So, it's taken care by the cfg_if! macro else clause now 2024-06-07 08:23:26 this change started in the v0.27.0 release. 2024-06-07 08:24:48 Yes, so nix 0.27.0 would be the lowest version with Loongarch support (if the ioctl portion of nix is used) 2024-06-07 08:26:06 Yes, I think so. 2024-06-07 09:21:51 Hi, all 2024-06-07 09:21:51 Just to say we're on holiday tomorrow and will be back next Tuesday. 2024-06-07 09:50:33 have fun! 2024-06-07 13:07:25 have a great time on holiday! 2024-06-07 13:22:24 (thanks znley for testing) 2024-06-09 01:22:10 :( 2024-06-09 01:22:27 and the conflicting advice from developers continues 2024-06-09 01:23:25 When i saw the request for putting Loongarch fixes in a case $CARCH statement, i thought it involved some kind of patch 2024-06-09 01:23:50 Then i click on the link, and it turns out it is just update_config_sub :'( 2024-06-09 01:25:17 which just copies a file included in the abuild package 2024-06-09 01:28:11 Too bad you all are on holiday, and won't be able to reply to that advice until 2 days later 2024-06-09 01:33:59 Maybe we can do it like that, for aports where requests are made that are not in line with the rest of aports (like update_config_sub/guess within case $CARCH, which i don't think i have ever seen in other aports) 2024-06-09 01:34:15 Perhaps in those cases you can give me permission to edit the MR, and just disable Loongarch 2024-06-09 01:39:58 I had a thought a while ago, that perhaps a check for whether update_config_sub/guess is needed could be added to checkapk, so maybe CI fails if that it needed, maybe if this is done, it should be in combination with checking arch=, if the archs for which update_config_sub/guess is needed are disabled, then it won't error out 2024-06-09 01:42:02 In that case, maintainers would be responsible to add the update_config_sub/guess line to ensure their aports work on all archs it is enabled for 2024-06-09 01:51:11 :( 2024-06-09 01:52:42 and now i scroll up, and see a request for putting libc crate updates within case statements 2024-06-09 01:58:40 Anyway, i feel conflicted about all this advice 2024-06-09 01:59:27 I think we've never put update_config_sub/guess and libc crate updates within case $CARCH statements before 2024-06-09 02:00:25 and that's the problem, we've never written down how update_config_sub/guess and libc crate updates should be done 2024-06-09 02:01:26 so, if you follow that advice, and add them within a case $CARCH, very soon, more aports will be doing that, and it will become the unwritten rule 2024-06-09 02:03:05 which will lead the the follow-up question, what if the update_config_sub/guess or libc crate update is needed for things like ppc64le/riscv64/s390x, do we then put them within case $CARH too?! 2024-06-09 02:05:15 I think it is better to just disable Loongarch in that case (i hope you all don't mind) 2024-06-09 02:07:47 because if we go down that road, soon there will be requests for every architecture-specific fix to be within case $CARCH, which will complicate things 2024-06-09 02:10:59 I would like to remind our readers that we are already applying Loongarch patches for the libc crate(s) in main/rust unconditionally, so why should we do it conditionally in Rust-compiled aports? 2024-06-09 02:14:46 In my opinion, such requests are just a polite way of asking for Loongarch to be disabled, and probably that is what you all can consider doing, unless the aport in question is really essential 2024-06-09 02:20:39 and since that is the case, maybe we can considering coming up with a new reason for disabling archs "# by maintainer request" 2024-06-09 02:21:35 s/since/if/ 2024-06-09 02:25:29 I think there are cases of something similar already, where some issue appeared on an arch and the maintainer disabled it with "# not interested in debugging issues on this arch" 2024-06-09 05:19:11 Anyway, sorry for the long rant, just a bit frustrated by the lack of coordination 2024-06-09 05:21:31 First, it was disagreements over whether pkgrel bumps are needed, and this is actually not that bad, it's just that it may find issues on other archs, and sometimes maintainers don't participate in fixing those, resulting in the MRs just sitting there, or getting accidentally merged and blocking the builders 2024-06-09 05:23:05 Now it's putting Loongarch changes within case "$CARCH", which unfortunately, in my opinion is a bit too much (especially when applied to update_config_sub/guess, and libc crate updates), this will over-complicate things, and make reasoning about APKBUILDs much harder 2024-06-09 05:24:37 and there's also the follow-up question, if we put Loongarch changes within case "$CARCH", are we going to do that for every change that is sort of arch-specific? 2024-06-09 05:25:42 That is just too complicated, maybe it would be easier if there was support within abuild to apply arch-specific patches, but that also complicates things and makes reasoning harder 2024-06-10 01:44:29 So..just ignore most of what i said above, the issue has sort of been resolved 2024-06-11 01:22:12 Hi,all we are back 2024-06-11 01:23:07 hope you had a good holiday 2024-06-11 01:23:20 znley: thanks again for testing task3 2024-06-11 01:23:38 mio:Thanks 2024-06-11 01:23:51 celie: thanks for raising the issue for loongarch64 2024-06-11 01:24:00 You mentioned "update_config_sub/guess or libc with in case $CARCH" earlier, I remember we have not added CARCH for loongarch64 (only a few compilation parameters will distinguish the architecture, similar to !66548) 2024-06-11 01:24:16 Maybe I remembered it wrong, if there is a specific package or MR, it may be better for me 2024-06-11 01:27:37 I was thinking about the request in !66639, but i've spoken to @omni and he has moved discussion of this issue to https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10142 2024-06-11 01:29:35 Yes, it is not the way of doing things we have been following all the time, which is why i was a bit surprised and typed such long messages 2024-06-11 01:31:07 but discussions about this have moved to abuild, and the specific Bat MR itself has 32-bit ARM issues that are solved by `cargo update`ing `unsafe-libyaml` to 0.2.10 (i've notified @omni about this) 2024-06-11 01:31:41 So, everything is okay for now, and you all don't need to add the case statement 2024-06-11 01:32:22 Otherwise it could be argued that Bat needs 2 case statments, loongarch64) to apply libc 0.2.155, and arm*) to apply unsafe-libyaml 0.2.10 2024-06-11 01:32:55 but @omni knows about this, and he will probably look into it later when he finds the time 2024-06-11 01:36:47 cely: OK, thanks for your information 2024-06-11 01:38:58 By the way, is N Copa back from vacation? 2024-06-11 01:44:18 Yes. Just wondering, do you have an approximate date for when the Loongarch machines will arrive in Europe? 2024-06-11 01:54:12 Thanks, I am still waiting for N Copa to provide a mailing address 2024-06-11 01:54:12 I have applied, and i want to confirm the number of machines with N Copa again 2024-06-11 01:54:12 Once everything is settled, it won't be long. 2024-06-11 01:54:52 Alright, that's good to hear 2024-06-11 01:55:56 So, N Copa is back, and you can probably contact him to ask about the details 2024-06-11 01:57:24 Yes 2024-06-11 02:10:45 What happens if a machine needs repair, N Copa just mails it back to you? 2024-06-11 02:44:14 We will test the machines before sending them to UE. In fact, I think the probability of problems is very small because we have been using the same machines. 2024-06-11 02:44:17 If there are any problems, we will fully support them. 2024-06-11 02:45:03