[英雄帖] Port VSCodium to LoongArch

[xen0n]

No description provided.

[xen0n]

I've tried to package a build agent container for loong64 based on Debian sid and the recently-merged riscv64 port, seems it's not currently feasible:

13.43 The following packages have unmet dependencies:
13.51  krb5-multidev:loong64 : Depends: libgssapi-krb5-2:loong64 (= 1.20.1-5.1) but it is not installable
13.51                          Depends: libk5crypto3:loong64 (= 1.20.1-5.1) but it is not installable
13.51                          Depends: libkrb5-3:loong64 (= 1.20.1-5.1) but it is not installable
13.51  libatomic1 : Breaks: libatomic1:loong64 (!= 14.1.0-2) but 14-20240330-1 is to be installed
13.51  libatomic1:loong64 : Depends: gcc-14-base:loong64 (= 14-20240330-1) but it is not installable
13.51                       Breaks: libatomic1 (!= 14-20240330-1) but 14.1.0-2 is to be installed
13.51  libc6:loong64 : Depends: libgcc-s1:loong64 but it is not going to be installed
13.51  libglib2.0-0t64:loong64 : Depends: libselinux1:loong64 (>= 3.1~) but it is not installable
13.51  libgssrpc4t64:loong64 : Depends: libgssapi-krb5-2:loong64 (>= 1.17) but it is not installable
13.51  libkadm5clnt-mit12:loong64 : Depends: libgssapi-krb5-2:loong64 (>= 1.17) but it is not installable
13.51                               Depends: libk5crypto3:loong64 (>= 1.6.dfsg.2) but it is not installable
13.51                               Depends: libkrb5-3:loong64 (>= 1.15~beta1) but it is not installable
13.51                               Depends: libkrb5support0:loong64 (= 1.20.1-5.1) but it is not installable
13.51  libkadm5srv-mit12:loong64 : Depends: libgssapi-krb5-2:loong64 (>= 1.6.dfsg.2) but it is not installable
13.51                              Depends: libk5crypto3:loong64 (>= 1.6.dfsg.2) but it is not installable
13.51                              Depends: libkrb5-3:loong64 (>= 1.15~beta1) but it is not installable
13.51                              Depends: libkrb5support0:loong64 (= 1.20.1-5.1) but it is not installable
13.51  libkdb5-10t64:loong64 : Depends: libk5crypto3:loong64 (>= 1.20) but it is not installable
13.51                          Depends: libkrb5-3:loong64 (>= 1.14+dfsg) but it is not installable
13.51                          Depends: libkrb5support0:loong64 (= 1.20.1-5.1) but it is not installable
13.51  libmount1:loong64 : Depends: libselinux1:loong64 (>= 3.1~) but it is not installable
13.51  libselinux1-dev:loong64 : Depends: libselinux1:loong64 (= 3.5-2+b1) but it is not installable
13.51  libsepol-dev:loong64 : Depends: libsepol2:loong64 (= 3.5-2) but it is not going to be installed
13.52 E: Unable to correct problems, you have held broken packages.

[xen0n]

• krb5: fails test, log
• libselinux: not sure why the built package wasn't picked up
• gcc-14: needs a bootstrap gnat-13

[xry111]

• krb5: fails test, log

FYI on LFS the test seems fine:

PYTHONPATH=../../../util VALGRIND="" python3 ./t_cccol.py 
LD_LIBRARY_PATH=`echo -L../../../lib | sed -e "s/-L//g" -e "s/ /:/g"` KRB5_CONFIG=../../../config-files/krb5.conf LC_ALL=C  ./t_cc
Testing miscellaneous error conditions
Starting test on /tmp/cctest.17943
Test on /tmp/cctest.17943 passed
Starting test on KEYRING:process:/tmp/cctest.17943
Test on KEYRING:process:/tmp/cctest.17943 passed
Starting test on MEMORY:/tmp/cctest.17943
Test on MEMORY:/tmp/cctest.17943 passed
Starting test on FILE:/tmp/cctest.17943
Test on FILE:/tmp/cctest.17943 passed

After the test finishes:

$ keyctl list @s
2 keys in keyring:
262917943: ----s-rv     0     0 user: invocation_id
 16095271: --alswrv  1000  1000 keyring: _krb___krb5_unique__

[darkyzhou]

I've recently started working on porting the VSCodium Remote Extension Host (REH) Server to the LoongArch architecture. By replacing several binaries in the existing x64 build with LoongArch equivalents, I managed to get it working successfully. I was able to connect to the server using the VSCodium client on Windows without any issues.

My next step is to build the VSCodium REH Server natively within a LoongArch build container to streamline the process and ensure better compatibility. After that, I might look into porting the VSCodium client itself to LoongArch.

[darkyzhou]

UPDATE: REH Server PR merged: VSCodium/vscodium#2087

My next steps:

1. Build some older versions of REH Server and add them to existing VSCodium releases
2. Purpose a PR for loong64 in https://github.com/jeanp413/open-remote-ssh
3. Work with lcpu-club for Electron on loong64, which seems to be the last obstacle from building the VSCodium client natively

[jiegec]

Electron on loong64 is entirely possible (you can see from https://github.com/loongson/electron/) but lots of work required.

[darkyzhou]

UPDATE:

• First VSCodium version with loong64 support released: https://github.com/VSCodium/vscodium/releases/tag/1.95.2.24313
• Open Remote SSH PR Add support for loong64 jeanp413/open-remote-ssh#175 merged and v0.0.47 released
• Now, anyone should be able to access a Loong64 machine using the latest VSCodium with latest Open Remote SSH.
• Work needed to port some extensions that doesn't "support" loong64. For example, rust-analyzer extension will refuse to be installed saying "unsupported platform", despite we could specify the rust-analyzer binary path manually in the configuration once installed.

Now I'm looking into porting Electron v32 itself.

[darkyzhou]

UPDATE: I have successfully compiled Electron 32.2.3 on Loong64 over this weekend and managed to run latest VSCodium with it.

Currently focusing on CI-related work to standardize the porting process and patches. Expect to complete the whole workflow by next weekend, and will submit a PR to VSCodium repository accordingly.

[darkyzhou]

UPDATE: VSCodium/vscodium#2121 VSCodium PR merged.
Special thanks to @jiegec for Chromium patches and advices.

Note that it requires glibc>=2.39 due to how loong64 port for electron is built.

[xen0n]

The VSCodium maintainers have retroactively built the 1.95.3 release for linux/loong64, and added the artifacts to the release page. Hence we consider this 英雄帖 to be finished, and congratulations to @darkyzhou who have gone all the way to make this happen!