obably do
without one for now.
I'll happily help if you are interested in this niche architecture; feel free
to reach out via mail or IRC.
[1]:https://github.com/xen0n/loongson-overlay
[2]:https://www.spinics.net/lists/linux-arch/msg76936.html
--
WANG Xuerui
xe...@gentoo.org
Gentoo Linux deve
On 4/18/22 02:23, Arthur Zamarin wrote:
On 17/04/2022 18.33, WANG Xuerui wrote:
## Roadmap update
Now that I have verified everything with stage builds and installation on
real Loongson 3A5000 hardware, I plan to first upstream the profiles and
toolchain bits to ::gentoo. After that, I&#x
LoongArch patchset.
The patchset is already integrated for sys-libs/glibc; this patch series
takes care of sys-kernel/linux-headers. Also the mask is added for extra
safety.
For people more comfortable with GitHub workflow, this is also posted at
https://github.com/gentoo/gentoo/pull/25162 .
WANG
Signed-off-by: WANG Xuerui
---
eclass/kernel-2.eclass | 2 ++
profiles/arch/base/package.use.mask | 1 +
2 files changed, 3 insertions(+)
diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index 02c70422ee07..9d9d3fbb6f96 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass
Signed-off-by: WANG Xuerui
---
profiles/arch/base/package.use.mask | 8
1 file changed, 8 insertions(+)
diff --git a/profiles/arch/base/package.use.mask
b/profiles/arch/base/package.use.mask
index 4683e58f9b8a..463227f1989c 100644
--- a/profiles/arch/base/package.use.mask
+++ b
Closes: https://github.com/gentoo/gentoo/pull/25162
Signed-off-by: WANG Xuerui
---
sys-kernel/linux-headers/Manifest | 1 +
...aders-5.17.ebuild => linux-headers-5.17-r1.ebuild} | 11 +--
sys-kernel/linux-headers/metadata.xml | 3 +++
3 files chan
On 4/23/22 14:25, Michał Górny wrote:
On Sat, 2022-04-23 at 13:15 +0800, WANG Xuerui wrote:
Signed-off-by: WANG Xuerui
---
eclass/kernel-2.eclass | 2 ++
profiles/arch/base/package.use.mask | 1 +
2 files changed, 3 insertions(+)
diff --git a/eclass/kernel-2.eclass b/eclass
- removed eclass changes; moved IUSE adjustment into ebuild
WANG Xuerui (2):
profiles/arch/base: mask sys-libs/glibc[experimental-loong]
sys-kernel/linux-headers: add experimental loong patchset
profiles/arch/base/package.use.mask | 9 +
sys-kernel/linux-header
Signed-off-by: WANG Xuerui
---
profiles/arch/base/package.use.mask | 8
1 file changed, 8 insertions(+)
diff --git a/profiles/arch/base/package.use.mask
b/profiles/arch/base/package.use.mask
index 4683e58f9b8a..463227f1989c 100644
--- a/profiles/arch/base/package.use.mask
+++ b
Closes: https://github.com/gentoo/gentoo/pull/25162
Signed-off-by: WANG Xuerui
---
profiles/arch/base/package.use.mask | 1 +
sys-kernel/linux-headers/Manifest| 1 +
...ders-5.17.ebuild => linux-headers-5.17-r1.ebuild} | 12 ++--
sys-kernel/li
On 4/23/22 21:58, Joonas Niilola wrote:
On 18.4.2022 7.47, WANG Xuerui wrote:
Of course I forgot to mention the devbox situation... The single box I
currently use is placed in my company, so I probably wouldn't be able to
share it. I have ordered another board though, so I'll
On 4/23/22 20:16, WANG Xuerui wrote:
Hi,
In order to support building for LoongArch in ::gentoo while some of the
necessary bits are not upstreamed yet, recently it was discussed in
#gentoo-toolchain that a new USE flag "experimental-loong" is to be
added, force-masked on every A
Signed-off-by: WANG Xuerui
---
eclass/acct-group.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass
index 56b76ba1885..3d02e4f713b 100644
--- a/eclass/acct-group.eclass
+++ b/eclass/acct-group.eclass
@@ -1,4 +1,4
Posting to mailing list mainly because of the eclass changes, however
trivial the changes might be. The portage patch is already upstream but
not in a tagged release yet.
This is part of the draft PR: https://github.com/gentoo/gentoo/pull/25183
over at GitHub.
WANG Xuerui (3):
acct
Signed-off-by: WANG Xuerui
---
eclass/acct-user.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
index c7c32086ad2..c87b27f3cca 100644
--- a/eclass/acct-user.eclass
+++ b/eclass/acct-user.eclass
@@ -141,7 +141,7
Signed-off-by: WANG Xuerui
---
.../portage/files/3.0.30-loong-abis.patch | 133 +
sys-apps/portage/portage-3.0.30-r5.ebuild | 277 ++
2 files changed, 410 insertions(+)
create mode 100644 sys-apps/portage/files/3.0.30-loong-abis.patch
create mode 100644 sys-apps
On 4/24/22 23:21, WANG Xuerui wrote:
Posting to mailing list mainly because of the eclass changes, however
trivial the changes might be. The portage patch is already upstream but
not in a tagged release yet.
This is part of the draft PR: https://github.com/gentoo/gentoo/pull/25183
over at
Hi,
On 4/25/22 01:57, Michał Górny wrote:
On Sun, 2022-04-24 at 23:21 +0800, WANG Xuerui wrote:
Signed-off-by: WANG Xuerui
---
.../portage/files/3.0.30-loong-abis.patch | 133 +
Why add a patch when we can make a new Portage release with this?
I saw many other changes on the
Hi,
This is https://github.com/gentoo/gentoo/pull/31241 and specific to
packaging of Rust (the compiler itself), but I'm also sending here for
wider review (e.g. in case I messed up some ports but didn't realize).
WANG Xuerui (3):
rust-toolchain.eclass: cosmetic clean
Re-tab the file, and reorganize the rust_abi and rust_all_arch_uris
helpers so the keys are sorted alphabetically while preserving match
order. No functional change intended.
See: https://github.com/gentoo/gentoo/pull/31241
Signed-off-by: WANG Xuerui
---
eclass/rust-toolchain.eclass | 70
Right now mips64el systems are treated as mips64 (big-endian) in the
rust_abi helper, that prevents installation of rust. Fix by checking for
mips64el before mips64.
See: https://github.com/gentoo/gentoo/pull/31241
Signed-off-by: WANG Xuerui
---
dev-lang/rust-bin/Manifest | 12
For less downloading client-side, as it is likely that only one package
in each covered group would work on a given system.
Closes: https://github.com/gentoo/gentoo/pull/31241
Signed-off-by: WANG Xuerui
---
dev-lang/rust-bin/rust-bin-1.65.0-r1.ebuild | 2 +-
dev-lang/rust-bin/rust-bin-1.66.1
Hi,
Here are some fixes to the recently added go-env.eclass that broke Go
ebuilds on several arches (loong and riscv confirmed). I've tested on
loong to confirm.
You can also view this series on GitHub [1], should you prefer that.
[1]: https://github.com/gentoo/gentoo/pull/33941
WANG Xuer
-lang/go to the
eclass and switches the go-env_set_compile_environment() function to use
that, to fix the problem at hand.
Fixes: 878d04daaf34765e6224e58139a9c45921d7a0c3
Closes: https://bugs.gentoo.org/917750
Signed-off-by: WANG Xuerui
---
eclass/go-env.eclass | 40
This is necessary for the build artifact to conform to the configured
ISA level and features on those arches. The logic is also taken from
the dev-lang/go ebuild.
Signed-off-by: WANG Xuerui
---
eclass/go-env.eclass | 21 +
1 file changed, 21 insertions(+)
diff --git a
s and trivial ebuild additions, in the
GitHub PR [1], I've been able to produce working kernels for both
Loongson 3A6000 (desktop) and 3C5000L (server).
Your review and comments are welcome!
[1]: https://github.com/gentoo/gentoo/pull/34291
WANG Xuerui (3):
dist-kernel-utils.eclass: support loo
The filenames to use are taken from upstream:
https://github.com/torvalds/linux/blob/v6.6/arch/loongarch/boot/Makefile.
Signed-off-by: WANG Xuerui
---
eclass/dist-kernel-utils.eclass | 7 +++
1 file changed, 7 insertions(+)
diff --git a/eclass/dist-kernel-utils.eclass b/eclass/dist-kernel
Right now the loong profiles in Gentoo only cover the 64-bit ISA, so we
can unconditionally specify loongarch64 for QEMU.
Signed-off-by: WANG Xuerui
---
eclass/kernel-install.eclass | 3 +++
1 file changed, 3 insertions(+)
diff --git a/eclass/kernel-install.eclass b/eclass/kernel
ng to near the end of eclass src_configure(), so the flag
correctly reflects the reality in all circumstances.
Signed-off-by: WANG Xuerui
---
eclass/kernel-build.eclass | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/eclass/kernel-build.eclass b/eclass/k
On 12/17/23 21:11, Michał Górny wrote:
On Sun, 2023-12-17 at 20:09 +0800, WANG Xuerui wrote:
The several partially-supported arches (those relying on
USE=savedconfig) directly return in src_prepare(), hence previously the
CONFIG_EFI_ZBOOT probing didn't have a chance to run when buildin
Hi everyone,
I'm your average Gentoo user who obviously thought his sleeping time is more
than enough, and just decided to start porting Gentoo to LoongArch. As this
is such a niche architecture with no upstreamed support so far, I'm posting
this to announce my intent and gather advice on how to
On 8/12/21 02:13, William Hubbs wrote:
On Thu, Aug 12, 2021 at 12:39:33AM +0800, WANG Xuerui wrote:
I'm planning to take ARCH=loongarch for the port; and support the LP64 ABI
first. I'd like to support both LP64 and ILP32 ABIs, but that's not a
priority.
The ABI flag
Hi Yixun,
On 2021/8/12 17:55, Yixun Lan wrote:
> HI Xuerui:
>
> This must be a *HUGE* project and gonna put lots of effort in to it!
> So, first, good luck to you with all my best wishes!~
Thanks for your kindness!
>
> On 00:39 Thu 12 Aug , WANG Xuerui wrote:
>> Hi
On 8/12/21 14:39, Ulrich Mueller wrote:
On Thu, 12 Aug 2021, Michał Górny wrote:
On Thu, 2021-08-12 at 09:21 +0800, WANG Xuerui wrote:
I would say this is mostly aesthetic matter, because we have equally
long ARCH names like "microblaze" or "openrisc" too. From a us
Hi Ulrich,
On 2021/8/24 16:46, Ulrich Mueller wrote:
>>>>>> On Tue, 24 Aug 2021, WANG Xuerui wrote:
>> It seems the discussion has gone quiet for a while now, so I take that
>> we choose ARCH=loong over ARCH=loongarch according to GLEP 53?
> LGTM
>
>> If
From: WANG Xuerui
The Linux port currently under review has arch/loongarch, and should
almost certainly remain that way till merge; meanwhile it's ARCH=loong
on the Gentoo side, per mailing list discussion[1] and eselect
adaptation[2]. This architecture is little-endian-only according t
On 2021/8/12 00:39, WANG Xuerui wrote:
> Hi everyone,
>
>
>
> ## Gentoo porting plans
>
> I'm planning to take ARCH=loongarch for the port; and support the LP64
> ABI
> first. I'd like to support both LP64 and ILP32 ABIs, but that's not a
> priority.
&
From: WANG Xuerui
There is only full support for the LP64D ABI in the initial upstream
submissions for the various low-level pieces, so full multilib
combinations are not pursued at the moment; but the expected library
search path of gcc (`lib64`) means the default of `lib` does not work
in our
Hi everyone,
I'm the guy who previously announced the Gentoo/LoongArch port [1];
since that post, some nice progress has been made, and here's a heads-up
and a procedural question regarding how to continue work upstream.
## Progress of the port
After some minimal forking and tweaking, it's
39 matches
Mail list logo
