2025-08-01 14:35:21 <cockliuser> hello
2025-08-01 14:36:20 <cockliuser> Does anyone know why this patch: [ https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/gcc/0005-On-linux-targets-pass-as-needed-by-default-to-the-li.patch ] isn't applied to loongarch?
2025-08-01 14:37:21 <cockliuser> Because as far as I can tell it leads to discrepancies like community/libopenmpt having a dependency on libogg on loongarch but not on other architectures
2025-08-02 01:41:30 <DWwanghao> Hi,cockliuser:sorry for the late reply - I remember you asked about this issue back in June
2025-08-02 01:41:43 <DWwanghao> This parameter is actually a linker parameter and is architecture-independent (loongarch64 supports it too)
2025-08-02 01:41:55 <DWwanghao> Let me run some local tests first, and then I'll submit a patch to GCC. Thanks for reporting this
2025-08-02 01:42:33 <DWwanghao> I'll also test whether the community/libopenmpt package can compile normally after removing the libogg dependency, and will handle that accordingly
2025-08-02 04:17:08 <DWwanghao> Hi, just updating the results: The GCC patch has been submitted at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/88144
2025-08-02 04:18:20 <DWwanghao> cockliuser:not sure if you're still around,my local tests show that community/libopenmpt can be compiled successfully even after removing the libogg dependency
2025-08-02 04:18:35 <DWwanghao> This aport shouldn't be related to GCC's compilation behavior anyway, as it's just a linker parameter
2025-08-02 08:33:43 <cockliuser> DWwanghao: Thank you for the response and for opening the MR!
2025-08-02 08:34:49 <cockliuser> libopenmpt doesn't have a direct dependency on libogg so when that PR gets merged and the package gets recompiled it should get the same deplist on all arches
2025-08-04 19:28:13 <Ariadne> i integrated the patch, but am postponing a rebuild because gcc 15.2.0 is about to be released.
2025-08-05 01:09:08 <DWwanghao> Thanks for integrating this.I've seen the relevant changes in commit 5cc8742a.
2025-08-05 08:00:40 <xen0n> PSA: there are now monthly group purchases of LoongArch HW shipping worldwide, kindly organized by the Loongson hobbyists community -- check out https://forms.gle/WYgH68tcTckPNjew6 for details
2025-08-05 08:03:23 <xen0n> some context: a month ago I've brought a LoongArch MATX board to DebConf 25 for demos, many people were excited about the hardware -- now we're going to make it easy to get real LoongArch HW for all communities
2025-08-08 06:33:24 <DWwanghao> Hi achill,the previous qt6-qtWebEngine build failure issue has been resolved by fixing the flexible array behavior of musl on LoongArch64. The local build was successful
2025-08-08 06:33:46 <DWwanghao> Here's the relevant MR:https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/88412
2025-08-08 06:34:02 <DWwanghao> It seems PureTryOut isn't in this channel. What's your opinion on this?
2025-08-08 06:34:58 <achill> looks like there is some discussion about the patch: https://www.openwall.com/lists/musl/2024/06/17/3
2025-08-08 06:35:06 <DWwanghao> I saw your comments under the MR - thanks for the review
2025-08-08 06:35:12 <achill> it would be helpful to get a opinion of the musl author on the patch
2025-08-08 06:38:51 <DWwanghao> Yes, I previously considered several approaches to resolve the QT6-* compilation issues
2025-08-08 06:38:58 <DWwanghao> either modify Chromium's implementation regarding the OwnedRefWrapper invocation pattern,or alter GCC's low-level handling to treat musl and glibc uniformly
2025-08-08 06:39:09 <DWwanghao> Both approaches seem likely to complicate matters further
2025-08-08 07:34:40 <DWwanghao> Hi ikke, not sure if you’re around right now, but may I ask you something
2025-08-08 07:35:38 <DWwanghao> Does LXC set different default max open files limits for different architectures when starting a container?
2025-08-08 07:36:09 <ikke> I'm not aware of any differences between arches 
2025-08-08 07:36:11 <DWwanghao> I noticed that on x86_64 it’s: Max open files  1073741816, while on loongarch it’s 4096. But in CI for loongarch it’s 1024,
2025-08-08 07:36:39 <DWwanghao> which causes the community/kdsingleapplication package’s stress test to fail with EINVAL, since it requires at least 4096
2025-08-08 07:37:14 <ikke> I can verify later if we set anything specific on the builders
2025-08-08 07:38:38 <DWwanghao> thank you very much:)
2025-08-08 10:32:50 <ikke> DWwanghao: I don't see on the builders (edge) that x86_64 has such a large ulimit
2025-08-08 10:33:05 <ikke> For the abuild process, this is what's reported:
2025-08-08 10:33:07 <ikke> Max open files            1024                 4096                 files
2025-08-11 09:25:58 <DWwanghao> ikke:thank you for the confirmation on the builders
2025-08-11 09:26:44 <raspbeguy> Hello, I wish to upgrade one of the package I'm in charge of. Usually upgrade goes smoothly but for this minor upgrade I now have a build error on loongarch64 https://gitlab.alpinelinux.org/raspbeguy/aports/-/jobs/1967212. I have no idea where it comes from so I would be glad to get some help
2025-08-11 09:28:08 <DWwanghao> Hi raspbeguy,I saw your message in the devel channel—I'll try to reproduce the issue locally
2025-08-11 09:29:18 <ikke> DWwanghao: where did you see that high max open files limit?
2025-08-11 09:32:35 <DWwanghao> ikke:when I started an x86_64 container via Docker on my local physical server and executed cat /proc/self/limits | grep "open files", the returned file descriptor limit was unusually high
2025-08-11 09:33:14 <ikke> DWwanghao: as root?
2025-08-11 09:33:46 <DWwanghao> yes
2025-08-11 09:34:45 <DWwanghao> tried adding echo statements in the code for testing in CI. An hour ago, the output was:Max open files 1048576 1048576 files
2025-08-11 09:34:54 <DWwanghao> GitLab was a bit unstable earlier, but now after the upgrade, I'll verify it again
2025-08-11 09:38:51 <ikke> DWwanghao: probably depends on how docker on the host is configured
2025-08-11 09:40:59 <ikke> in openrc (and alpine in general) the hard limit is 4096. One one system in docker, I see an hard limit of 524288. On docker on alpine, I see a hardlimit of 1048576
2025-08-11 09:41:30 <ikke> The soft limit seems to be 1024 in both cases
2025-08-11 09:44:26 <DWwanghao> Yes, the lower limit is consistently 1024, so I'm verifying the echo output in CI: https://gitlab.alpinelinux.org/DWwanghao/aports/-/pipelines/350124
2025-08-11 09:45:05 <ikke> Ok, so that's consistent with what I see
2025-08-11 09:46:55 <ikke> Even with that amount of max open files, it still fails?
2025-08-11 09:48:24 <ikke> interesting, on loongarch, even the soft limit appears to be 1048576 by default
2025-08-11 09:49:35 <DWwanghao> Yes, the echo output shows:Max open files 1048576 1048576 files ,but it still fails
2025-08-11 09:49:40 <ikke> https://tpaste.us/ZKzo 
2025-08-11 09:50:00 <ikke> DWwanghao: then it seems something is abnormal
2025-08-11 09:50:02 <DWwanghao> strangely, I don't encounter this issue on the physical machine
2025-08-11 09:50:33 <ikke> I don't think the ulimit on it's own is the issue, it's just opening files until it hits a limit
2025-08-11 09:50:57 <ikke> I forgot one package, but there was one which hit a similar issue
2025-08-11 09:51:54 <DWwanghao> https://tpaste.us/doNj
2025-08-11 09:52:40 <DWwanghao> I previously tested it manually this way, and the build worked fine
2025-08-11 09:54:19 <DWwanghao> Haha, that's probably some ancient memory. Anyway, being able to consistently reproduce the issue makes troubleshooting much easier
2025-08-11 09:54:41 <ikke> nod
2025-08-11 14:16:00 <achill> can somebody help me out re https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1957351#L3543?
2025-08-11 14:16:02 <achill> can i just remove the mv vmlinuz-$_abi_release vmlinuz-$_buildflavor in the APKBUILD or how is the linux image now called
2025-08-11 14:16:05 <achill> i dont have a loongarch machine so any help from someone who can quickly look over is appreciated
2025-08-11 14:16:05 <achill> 
2025-08-11 14:16:19 <achill> maybe i should look at some loongarch related kconfig changes
2025-08-12 08:15:47 <DWwanghao> Hi raspbeguy,alloy 1.10.1 fails due to R_LARCH_B26 overflow—the 26-bit jump instruction offset range on LoongArch64 is insufficient
2025-08-12 08:16:07 <DWwanghao> adding $CGO_CFLAGS -mcmodel=extreme resolves the problem. I've tested it locally without issues
2025-08-12 08:16:32 <DWwanghao>  and I have already added a comment under your MR. If the CI still fails, feel free to provide feedback anytime
2025-08-12 09:24:40 <DWwanghao> achill:after the LoongArch build is completed, three files should be generated in the /boot directory: System.map, config, and vmlinuz.the filename should be vmlinuz-stable
2025-08-12 09:42:47 <DWwanghao> I checked locally, and it's indeed as I mentioned above:https://tpaste.us/N5yB
2025-08-12 10:20:23 <mps> DWwanghao: why in your messages missing space char after ':'
2025-08-12 10:30:50 <DWwanghao> mps: Lol, finger slip
2025-08-12 10:43:13 <raspbeguy> DWwanghao: thank you very much. I will try after lunch break
2025-08-12 10:47:49 <DWwanghao> you are welcome
2025-08-12 11:01:36 <mps> DWwanghao: also, config-6.16.0-0-stable should be named config-stable
2025-08-12 11:02:06 <mps> and System.map-stable
2025-08-12 11:02:31 <mps> to not linger after upgrade
2025-08-12 11:10:58 <DWwanghao> mps: yes, these are the files before the mv operation. After renaming, all files were properly renamed
2025-08-12 11:11:05 <DWwanghao> achill's CI logs show that there was no vmlinuz-6.16.0-0-stable file prior to the renaming—only vmlinuz-stable existed
2025-08-16 11:23:54 <qaqland> https://github.com/bytecodealliance/rustix/issues/1496
2025-08-16 11:25:00 <qaqland> rustix crate (1.0.8) broken with libc crate (0.2.175)
2025-08-18 01:25:42 <DWwanghao> qaqland: thanks for your report. libc has been downgraded to 0.2.174
2025-08-18 01:25:45 <DWwanghao> https://github.com/rust-lang/cargo/pull/15851/files
2025-08-18 20:58:48 <achill> hey another issue im having
2025-08-18 20:59:23 <achill> i tried to boot linux-stable on a LS3A6000 but the kernel panicked
2025-08-18 20:59:26 <achill> https://paste.sr.ht/~fossdd/456dc634d9caf7d8df13ba095f549322b4fc0385
2025-08-18 20:59:56 <achill> it worked with linux-lts (6.12.42), linux-stable 6.15.10 and 6.16.1 dont work
2025-08-18 21:01:05 <achill> i would guess it being some config option that didnt got migrated with olddefconfig, but dunno
2025-08-19 01:52:53 <DWwanghao> achill: I also tested linux-stable 6.15.10 on the 3A6000-7A2000 machine, and it crashed as well
2025-08-19 01:53:14 <DWwanghao> After comparing the LoongArch configuration files of LTS and stable, I found that some configuration options are missing in stable
2025-08-19 01:53:22 <DWwanghao> https://tpaste.us/7omj
2025-08-19 01:54:15 <DWwanghao> This should be in line with your suspicion — the issue is likely caused by configuration options not being fully migrated