RE: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config
> USE=-native-symlinks removes a bunch of links that most packages use by
> default
> until are overridden explicitly. Incomplete list is:
> - /lib/cpp
> - /usr/bin/{gcc,cc,g++,c++,...}
> - /usr/bin/{as,ld,ranlib,dwp,...}
>
> The rule of thumb is: if a tool does not have ${CTARGET}- prefix it will
> probably
> disappear with USE=-native-symlinks.
>
> (At least eventually) 'emerge' should still be able to build most of packages
> in such environment. I expect initial breakage will be huge though.
>
> Using './configure && make && make install' style workflow will be more
> tedious.
> One workaround at least for gcc is to use something like:
> $ PATH="$(gcc-config -B):$PATH"
> It's not perfect. We'll see if toolchain can provide nicer environment.
>
Do we currently have (or is there a plan for) a mechanism to manage the
symbolic links and/or create them after merging the package when necessary?
It's quite tiresome to type in $CHOST-gcc for simple everyday tasks.
Regards,
--
Pengcheng Xu
https://jsteward.moe
openpgp-digital-signature.asc
Description: PGP signature
Re: [gentoo-dev] Announcing RISC-V
Hi!
2019年5月5日(日) 0:32 Tobias Klausmann :
>
> Hi!
>
> On Fri, 03 May 2019, Andreas K. Huettel wrote:
> > after some preparations, we're happy to announce (initially experimental)
> > support for a new arch: riscv
> >
> > * The project page is at https://wiki.gentoo.org/wiki/Project:RISC-V
> > Feel free to join if you want to help and/or even have hardware.
> > We also have a dedicated IRC channel, #gentoo-riscv
> >
> > * The keyword is "~riscv"; no stable keyword will be used in the beginning.
> >
> > * We will initially add two profiles to profile.desc:
> > default/linux/riscv/17.0/rv64gc/lp64d (non-multilib, 64bit hardfloat)
> > default/linux/riscv/17.0/rv64gc (multilib lp64d/lp64, i.e. hard/softfloat)
> >
> > * Stage builds have been tested with an overlay and work fine.
> > I'll publish initial stage3 images soon and will work with releng to get
> > autobuilds running.
> >
> > * Once this all is done I'll draft an announcement for the main web page.
>
> I'm a sucker for exotic arches. What is the recommended hardware
> to use to be able help with testing?
SiFive's "Hifive Unleashed" seems to be the best RISC-V dev-board
available: quad-core at 1.5GHz with 8GB RAM in 28nm. Link:
https://www.sifive.com/boards/hifive-unleashed
Currently working on the board with jiegec at #gentoo-riscv.
>
> Best,
> Tobias
>
> --
> printk ("Barf\n");
> linux-2.6.6/arch/v850/kernel/module.c
>
Yours,
--
Pengcheng
[gentoo-dev] Introducing SharkBait: Gentoo GSoC 2018 project to manage Android with Portage
Dear all, I'm Pengcheng Xu, one of the participants in Gentoo Google Summer of Code 2018, with Benda (heroxbd) Xu as my mentor. I've been working on the project SharkBait [1] (previously known as Portage-powered Android), which aims to manage the build and update process of Android systems with Portage. Development details can be found on my personal blog [2]. I've recently delivered a talk on the Software Freedom Day event at Tsinghua University, China on September 22nd about the SharkBait project. The talk slides are attached and should serve as a concise introduction. We've finished booting Android in LXC while having OpenRC as the service manager for the rest of the system. Work to build Android components with Portage has started, and we have successfully built bionic (Android's libc) with Portage on amd64, but there are a few issues left on ARM. If you're interested, follow the porting guide at [3] to get started with your Android device. The slides contain a slightly more detailed overview of porting a device, while the wiki page holds all the details to get a port up and running. We're planning to implement an eclass for Soong, the AOSP build system, and develop mechanisms to automatically convert Soong metadata to ebuilds. We may have to figure out how to build Java parts of Android (gradle mostly) elegantly with Portage. In this way, we can achieve the final goal of the project, that is, to manage Android update process with Portage. I've always been looking forward to responses from Gentoo developers, so please tell me what you think about the project as well as questions. Thanks! [1]: https://www.shark-bait.org/ [2]: https://jsteward.moe/ [3]: https://wiki.gentoo.org/wiki/Android/SharkBait/Porter_Guide Sincerely, -- Pengcheng Xu i...@jsteward.moe
Re: [gentoo-dev] Current state of arm and arm64 architecture in Gentoo Linux
Then I'll use the arm64 stage for my project. Thanks for the information! 2018年5月1日(火) 3:52 Alec Warner <anta...@gentoo.org>: > On Mon, Apr 30, 2018 at 7:39 AM, Pengcheng Xu <i...@jsteward.moe> wrote: > >> Hi all, >> >> I'm currently working on my Gentoo GSoC project ( >> https://summerofcode.withgoogle.com/projects/#5132157995974656 ), and >> I'm wondering what's the current work state of Gentoo Linux's arm >> architecture. The last stage3 tarball update date was 20161127, and, as >> it's quite dated compared to popular architectures (e.g. amd64), does that >> mean the architecture is no longer actively maintained anymore? >> >> And I've read about the arm64 architecture for Gentoo Linux. Is that >> still considered experimental for now? >> >> > packages.gentoo.org should have support for arm64 soon. Its queued behind > some security related updates. > > -A > > >> Thanks in advance, >> >> -- >> Pengcheng Xu (KireinaHoro) >> School of EECS >> Peking University >> i...@jsteward.moe >> >>
[gentoo-dev] Current state of arm and arm64 architecture in Gentoo Linux
Hi all, I'm currently working on my Gentoo GSoC project ( https://summerofcode.withgoogle.com/projects/#5132157995974656 ), and I'm wondering what's the current work state of Gentoo Linux's arm architecture. The last stage3 tarball update date was 20161127, and, as it's quite dated compared to popular architectures (e.g. amd64), does that mean the architecture is no longer actively maintained anymore? And I've read about the arm64 architecture for Gentoo Linux. Is that still considered experimental for now? Thanks in advance, -- Pengcheng Xu (KireinaHoro) School of EECS Peking University i...@jsteward.moe pgpjaekpNskDa.pgp Description: PGP signature
Re: [gentoo-dev] Mailing list moderation and community openness
I can understand the need to reduce meaningless spams on the dev list, but seems like general rejection of posts from non-developers would distract the idea of this being an open mailing list: a list that one can’t post to effectively decays to something like a bulletin board, and obviously the developing process shouldn’t be kept in a showcase, which would greatly discourage people who are not part of the dev team, yet still wanting to get involved in the discussing, maybe even decision-making. Pengcheng Xu i...@jsteward.moe > H30/03/20 20:17、Michael Palimaka <kensing...@gentoo.org>のメール: > > I see that in bug #650964[1] Council is pushing forward again with > implementing user whitelisting on this mailing list (ie. anyone that is > not "approved" will have their mail rejected). > > Could someone please explain how this doesn't directly contradict the > core tenets of an open and inclusive community? > > 1: https://bugs.gentoo.org/650964 > signature.asc Description: Message signed with OpenPGP
