2025-05-02 09:39:16 <mps> lindsay: do you need intel XE GPU driver enabled on loongarch64 also
2025-05-02 10:05:58 <lindsay> mps: I don't have a loongarch machine at the moment, but I think it would be nice to enable it on loongarch.
2025-05-02 10:11:41 <lindsay> Sorry for the late reply, I was traveling on vacation. I'll reply the issue comment lately.
2025-05-02 10:45:39 <mps> lindsay: ok, i will enable it
2025-05-02 10:46:46 <mps> lindsay: np, my loongarch64 is off line currently. i will do this a little later
2025-05-02 10:48:00 <mps> cul, i will be afk for some time
2025-05-02 11:15:47 <mps> lindsay: enabled and pushed to builders
2025-05-02 11:23:02 <lindsay> Thank you!
2025-05-02 11:26:32 <mps> np
2025-05-08 05:49:29 <mps> will we have mesa 25.1 in 3.22 release
2025-05-08 06:57:07 <fossdd|m> we should probably wait for 25.1.1 first
2025-05-08 07:11:48 <mps> not sure, I'm using 25.1-rc series for more than 3 weeks quite fine
2025-05-08 07:12:40 <mps> fossdd|m: btw, i commented 25.1.0 MR
2025-05-08 07:14:31 <mps> https://tpaste.us/wap5
2025-05-08 07:14:50 <mps> it is simple addition
2025-05-08 07:30:37 <fossdd|m> applied
2025-05-08 07:31:24 <fossdd|m> im still confused about about armhf enabling clc, there seem to be some meson refactorings
2025-05-08 07:49:51 <mps> I'm waiting for disk upgrade to check is clc needed. But i think it is needed for asahi. will inform you later today when I test
2025-05-08 08:11:56 <mps> meson.build:833:12: ERROR: Dependency "libclc" not found, tried pkgconfig
2025-05-08 08:12:44 <mps> if remove libclc-dev from makedepends
2025-05-08 08:13:34 <fossdd|m> libclc should only be required and enabled for rusticl which isnt enabled for armhf
2025-05-08 08:14:08 <fossdd|m> im sure its fine to add it to dependencies and everything it needs but i dont know what gets enabled with it
2025-05-08 08:14:19 <mps> fossdd|m: btw, MR builds fine on my armv7 dev lxc
2025-05-08 08:14:59 <fossdd|m> nice
2025-05-08 08:15:17 <mps> I didn't added it to main mesa APKBUILD
2025-05-08 08:15:45 <mps> but know it is needed for asahi
2025-05-08 08:38:28 <mps> `inxi -G` shows thin on my macbook m1pro => https://tpaste.us/JNZv
2025-05-08 08:39:50 <fossdd|m> but armhf shouldnt have asahi enabled right?
2025-05-08 08:41:34 <mps> right, only aarch64 should
2025-05-08 08:43:39 <mps> oh, s/thin/this/  above
2025-05-08 10:06:20 <mps> fossdd|m: obviously rusticl/libclc is not needed on armhf iiuc all this
2025-05-08 10:08:32 <mps> (look like someone copied some things from testing/mesa-asahi to main/mesa, and I didn't make mesa-asahi "clean")
2025-05-08 10:10:37 <mps> oh, mesa-next but i didn't uploaded anywhere on alpine
2025-05-08 10:10:53 <mps> strange
2025-05-08 10:27:35 <mps> hm, mesa should be renamed to mess :)
2025-05-08 10:28:38 <mps> I give up to try to understand all these dependencies
2025-05-08 11:14:45 <fossdd|m> i can look again later today i guess
2025-05-08 11:30:54 <mps> would be nice to merge it for 3.22-stable, and we remove mesa-asahi then
2025-05-12 09:20:26 <cely> Is build-3-22-loongarch64 offline?
2025-05-12 10:19:05 <ncopa> seems like it is online
2025-05-12 10:19:15 <ncopa> oh
2025-05-12 10:19:41 <ncopa> openjdk was boostrapped
2025-05-12 10:44:30 <cely> Thanks
2025-05-15 09:21:50 <cely> I think jdk17 also has the issue that the -loongarch variant can build the normal variant, but not the other way round, so it looks like openjdk17-loongarch will need bootstrapping now
2025-05-15 09:21:56 <cely> Sorry for not realizing this earlier
2025-05-15 09:29:59 <cely> (so installing openjdk17-loongarch from edge and building 3.22 openjdk17-loongarch should allow it to pass)
2025-05-15 09:30:27 <cely> Whenever that's convenient
2025-05-15 09:31:21 <cely> Loongarch is less than 30 aports away from completing community anyway :)
2025-05-15 10:59:26 <ikke> cely: I did bootstrap it already
2025-05-15 11:00:15 <ikke> hmm, interesting
2025-05-15 11:02:20 <ikke> Oh, right
2025-05-15 11:03:54 <ikke> will bootstrap the loongarch64 variant as well
2025-05-15 11:11:25 <cely> Thanks
2025-05-15 11:47:24 <ikke> It's built now
2025-05-15 11:55:53 <cely> Ok :)
2025-05-21 08:52:25 <mps> x86_64 CI: no space left on device
2025-05-21 12:07:12 <ncopa> huh, again
2025-05-22 11:32:54 <mps> how setup-disk with 'crypt' and later 'sys' encrypt drive? whole disk or else?
2025-05-22 11:56:26 <mps> and why setup-disk still no asks if user wants swap at all
2025-05-22 12:08:50 <mps> ok, I found answer to question about crypt
2025-05-22 12:10:04 <mps> last about this, can the disk crypt key be on external media?
2025-05-22 14:25:41 <ncopa> yes, i think it can
2025-05-22 16:55:54 <mps> ok, it can but how to do this in alpine
2025-05-22 17:21:39 <ncopa> i think there is a boot option for a block device where key is stored
2025-05-22 17:26:40 <mps> yes, it can be set
2025-05-22 17:27:26 <mps> I meant external media as setup-disk
2025-05-22 17:27:55 <mps> didn't found in source
2025-05-22 18:11:09 <mps> btw, good guide about disk encryp is https://wiki.archlinux.org/title/Dm-crypt/Device_encryption
2025-05-23 15:33:55 <mps> arm developers machine is off-line?
2025-05-23 15:47:31 <mps> or hang
2025-05-23 17:25:41 <ikke> It just became reachable again
2025-05-23 17:43:46 <mps> thank you
2025-05-23 17:44:39 <mps> oh, can't ping
2025-05-23 17:46:32 <ikke> Ipv4 does not seem to work yet
2025-05-23 17:46:56 <mps> ah
2025-05-28 10:58:39 <ncopa> hi!
2025-05-28 10:59:05 <ncopa> I have a really weird issue with base64 on loongarch
2025-05-28 10:59:29 <ncopa> busybox base64 that is
2025-05-28 11:00:03 <ncopa> $ tpaste < nvme 
2025-05-28 11:00:03 <ncopa> https://tpaste.us/6KBn
2025-05-28 11:00:16 <ncopa> thats the script, with base64 data
2025-05-28 11:00:46 <ncopa> curl https://tpaste.us/6KBn > nvme
2025-05-28 11:01:18 <ncopa> actually let me extrat the data itself
2025-05-28 11:02:45 <ncopa> oh, its not base64 thats the problem
2025-05-28 11:04:18 <ncopa> not sure what is the problem
2025-05-28 11:04:22 <ncopa> but here is a reproducer:
2025-05-28 11:04:26 <ncopa> curl --silent https://tpaste.us/VYkd | base64 -d | dd bs=32 skip=96 count=1 2>/dev/null | hexdump -C
2025-05-28 11:04:46 <ncopa> in my x86_64 i get:
2025-05-28 11:04:54 <ncopa> 00000000  00 00 00 00 00 00 00 00  00 00 78 76 64 61 20 20  |..........xvda  |
2025-05-28 11:04:54 <ncopa> 00000010  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |
2025-05-28 11:04:54 <ncopa> 00000020
2025-05-28 11:05:09 <ncopa> on loongarch64 I get:
2025-05-28 11:05:24 <ncopa> ncopa-loongarch64:~/mdev-conf$ curl --silent https://tpaste.us/VYkd | base64 -d | dd bs=32 skip=96 count=1 2>/dev/null | hexdump -C
2025-05-28 11:05:24 <ncopa> *
2025-05-28 11:05:24 <ncopa> 00000020
2025-05-28 11:05:24 <ncopa> 00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
2025-05-28 11:06:55 <ncopa> ok. its not base64. its dd
2025-05-28 11:07:04 <ncopa> $ curl --silent https://tpaste.us/VYkd | base64 -d | sha1sum 
2025-05-28 11:07:04 <ncopa> 3db02f4fdc45f11a39b308075bafbf86527a9f8f  -
2025-05-28 11:07:18 <ncopa> same on both
2025-05-28 11:07:51 <ncopa> yup. I'm pretty sure busybox dd is broken
2025-05-28 11:08:01 <ncopa> on loongarch64 that is
2025-05-28 11:08:38 <ncopa> with GNU coreutils' dd it works
2025-05-28 11:08:48 <ncopa> 00000000  00 00 00 00 00 00 00 00  00 00 78 76 64 61 20 20  |..........xvda  |
2025-05-28 11:08:48 <ncopa> ncopa-loongarch64:~/mdev-conf$ curl --silent https://tpaste.us/VYkd | base64 -d | dd bs=32 skip=96 count=1 2>/dev/null | hexdump -C
2025-05-28 11:08:48 <ncopa> 00000010  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |
2025-05-28 11:08:48 <ncopa> 00000020
2025-05-28 11:20:38 <ncopa> wow. its flaky
2025-05-28 11:20:51 <ncopa> 1+0 records in
2025-05-28 11:20:51 <ncopa> ncopa-loongarch64:~/aports/main/busybox/src/busybox-1.37.0$ curl --silent https://tpaste.us/VYkd | base64 -d | dd bs=32 skip=96 count=1| sha1sum 
2025-05-28 11:20:51 <ncopa> e1010f416f911cff88512716898a68c55f1ab12c  -
2025-05-28 11:20:51 <ncopa> 32 bytes (32B) copied, 0.109878 seconds, 291B/s
2025-05-28 11:20:51 <ncopa> 1+0 records out
2025-05-28 11:20:52 <ncopa> ncopa-loongarch64:~/aports/main/busybox/src/busybox-1.37.0$ curl --silent https://tpaste.us/VYkd | base64 -d | dd bs=32 skip=96 count=1| sha1sum 
2025-05-28 11:20:52 <ncopa> de8a847bff8c343d69b853a215e6ee775ef2ef96  -
2025-05-28 11:20:54 <ncopa> 1+0 records out
2025-05-28 11:20:54 <ncopa> 1+0 records in
2025-05-28 11:20:56 <ncopa> 32 bytes (32B) copied, 0.108721 seconds, 294B/s
2025-05-28 12:08:13 <ncopa> ok, it can be solved with iflag=fullblock
2025-05-28 19:26:57 <Ariadne> weird!
2025-05-28 21:24:25 <ncopa> unexpected, but apparently it can happen that it does not read the entire block from a pipe unless iflag=fullblock is set