Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-10 Thread Benda Xu
Hi William, William Hubbs writes: > No one has offered to switch from eudev to udev and look at > regressions. People are asking me to show what features exist in udev > that aren't in eudev. I stuck with udev. I don't use eudev so I don't > know. I don't think imposing a personal preference

Re: [gentoo-dev] rfc: switching default udev provider for new systems to udev

2020-08-09 Thread Benda Xu
William Hubbs writes: >> William - can you actually elaborate on WHY you want to change things? >> Is there some problem with eudev? Is it actively maintained and >> generally tracking upstream udev commits (minus whatever they >> intentionally don't want to accept)? > > It is maintained

Re: [gentoo-dev] Packages up for grabs due to jlec being MIA

2020-08-05 Thread Benda Xu
Michał Górny writes: >> The following packages are looking for a new maintainer: >> > > + cuda.eclass I would like to adopt this eclass on behalf of the science project. Yours, Benda signature.asc Description: PGP signature

Re: [gentoo-dev] Gentoo/OpenBSD current status

2020-05-30 Thread Benda Xu
Aisha Tammy writes: > I've been trying to play around with the prefix and reading the > code. Basically trying to get it to work for my system. I've not > managed to get even a small headstart and am quite lost to say the > least. I was wondering if the openbsd prefix support is something >

[gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

2020-04-18 Thread Benda Xu
Hi Samuel, Samuel Bernardo writes: > My point is about other JVM languages such as scala, groovy, kotlin, > clojure, ... And about builders such as gradle or sbt? > > I think that eclasses for those would be very useful to develop > ebuilds and evolve with the right procedures. That's a good

Re: [gentoo-dev] [gentoo-java][PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

2020-04-10 Thread Benda Xu
Hi Samuel, Samuel Bernardo writes: > I send this email to mention that it seems to be missing eclasses for > JVM builders such as those I mention in this email subject. Dependencies > and tasks management are hard tasks now that I think to have great scope > for improvement. Have you read the

Re: [gentoo-dev] [PATCH] eclass/acct-user.eclass: disable fcaps() on Prefix.

2020-03-07 Thread Benda Xu
Michał Górny writes: > ^ wrong subject. OK. should be `acct-user.eclass: disable fcaps() on Prefix.` > On Sun, 2020-03-08 at 12:20 +0800, hero...@gentoo.org wrote: >> From: Benda Xu >> >> Gentoo Prefix runs with a normal user and cannot grant extra >>

Re: [gentoo-dev] [PATCH] eclass/acct-user.eclass: disable pkg_* on Prefix.

2020-02-18 Thread Benda Xu
Michael 'veremitz' Everitt writes: > Peanut gallery says 'ACK' +1 Thank you veremitz. Let's see :) Benda signature.asc Description: PGP signature

Re: [gentoo-dev] Ebuild Generators

2020-02-11 Thread Benda Xu
Tom Gillespie writes: > For historical curiosity there was also > https://github.com/domenkozar/g-pypi at one point (similar to > https://github.com/rafaelmartins/g-octave). Having used g-octave, the > primary issue is as Michał says, there are a lot of corner cases that > the generation doesn't

Re: [gentoo-dev] Ebuild Generators

2020-02-03 Thread Benda Xu
Hi Gerion, Gerion Entrup writes: >> Yes, that makes a lot of sense. The R overlay follows this model. Most >> of the ebuilds are automated. When an ebuild generation fails, we add >> the ebuild manually, understand it and then update the generator to >> cover it in the future. > > Is this

[gentoo-dev] Ebuild Generators (Was: GSoC 2020: Call for mentors and project ideas)

2020-02-02 Thread Benda Xu
Hi Gerion, Gerion Entrup writes: > I saw the idea „Big Data Infrastructure by Gentoo“ and found it kind of > interesting. However, I have a little bit the fear that a full automation > won't be possible and the whole project becomes a little bit like g-sorcery > (gs-pypi, gs-elpa) or g-octave:

Re: [gentoo-dev] GSoC 2020: Call for mentors and project ideas

2020-02-02 Thread Benda Xu
Dear Fellows, alicef writes: > As always, Gentoo plans to participate in the Google Summer of Code > 2020. We are looking for new project ideas and are always open for > new mentors. > Google Summer of Code is a big opportunity for making Gentoo project more > visible and get more people

Re: [gentoo-dev] GSoC 2020: Call for mentors and project ideas

2020-01-25 Thread Benda Xu
Thank you Alice! alicef writes: > As always, Gentoo plans to participate in the Google Summer of Code > 2020. We are looking for new project ideas and are always open for > new mentors. > Google Summer of Code is a big opportunity for making Gentoo project more > visible and get more people

Re: [gentoo-dev] Migrate away from python-2 or not

2019-12-03 Thread Benda Xu
Hi guys, Thank you very much for your comments. I have made up my mind to just help remove python 2.7. Actually, a lot of efforts are ongoing, for example, https://github.com/gentoo/gentoo/pull/13771 Cheers, Benda

[gentoo-dev] Migrate away from python-2 or not

2019-11-24 Thread Benda Xu
Dear all, Bug 684962 (dev-python/ipython-7.5.0: package conflicts) has demonstrated a painful consequence when upstream start to release python3 only versions. Upstream has dropped python-2.7 support in dev-python/ipython-7.5.0, thus there is no python_targets_python2_7 USE flag for the ebuild.

Re: [gentoo-dev] separate /usr without initramfs

2019-10-27 Thread Benda Xu
Joshua Kinard writes: > Put simply, the kernel's single purpose, as nothing more than a > hyper-complex while loop, is to get the hardware up into a usable state and > then hand off to userland, then sit and service userland's needs as called > upon. The kernel should have all of the subsystems

[gentoo-dev] Re: [gentoo-dev-announce] Gentoo CI news: pkgcheck is now running truly parallel

2019-10-08 Thread Benda Xu
Michał Górny writes: > Just a quick note: thanks to hard work of radhermit, the newest release > of pkgcheck features internal parallelization of checks. While it's not > perfect and there's still room for improvement (I mean, it could run > even faster!), it's a major step forward. > > This

Re: [gentoo-dev] Re: [PMS] [PATCH] Correct the definition of ESYSROOT as EPREFIX isn't always applicable

2019-07-31 Thread Benda Xu
Hi James, James Le Cuirot writes: >> > What if we want to bootstrap a brand new prefixed system using the >> > crossdev system as SYSROOT? This is the distinct SYSROOT case. The >> > problem is that there is no distinct variable for SYSROOT's prefix >> > and, as already stated, ESYSROOT is

Re: [gentoo-dev] [PATCH eclass-manpages] Allow @INCLUDES_EPREFIX for path functions

2019-07-30 Thread Benda Xu
Michał Górny writes: > Add a new @INCLUDES_EPREFIX tag that indicates that a particular > function (= getter) or variable is a path that includes ${EPREFIX}. > This will be used in pkgcheck to detect accidental variable and getter > combinations that result in double prefix. > > Signed-off-by:

[gentoo-dev] Re: [PMS] [PATCH] Correct the definition of ESYSROOT as EPREFIX isn't always applicable

2019-07-30 Thread Benda Xu
Hi James, Sorry that I have re-ordered your text. > A check was added to Portage to ensure this held. Myself, the > ChromiumOS team, and others have since been caught out by this check > when trying to bootstrap brand new systems from scratch. You cannot > bootstrap with no headers at all! The

Re: [gentoo-dev] RFC: isodate for packages.mask starting on 2019-07-01

2019-06-29 Thread Benda Xu
Hi Jonas, Jonas Stein writes: > Dear all, > > Situation: > We have different date formats in packages.mask. > > Change: > I suggest that we start using the date format -mm-dd > for all dates in packages.mask > starting with 2019-07-01 For me isodate is more readable. I would vote for this

[gentoo-dev] Re: Why aren't GSoC projects affecting ::gentoo discussed on regular mls?

2019-06-27 Thread Benda Xu
Hi Marek, Marek Szuba writes: > On 2019-06-27 04:16, Benda Xu wrote: > >> Michał, you were overreacting to the word "GSoC" since our original RFC >> at gentoo-dev. Please, just ignore GSoC when you are executing your >> experise of QA. Gentoo should be d

Re: [gentoo-dev] [PATCH 0/2] RFC: Introducing ldso switching to BLAS/LAPACK

2019-06-27 Thread Benda Xu
Mike Gilbert writes: > This looks a lot safer than yesterday's patch since there are no > ebuild removals here. Thank you Mike. > If/when you do want to remove old ebuilds, I suggest creating a github > PR, and let the CI bot check reverse dependencies. Yeah, that would have been a much

[gentoo-dev] Re: Why aren't GSoC projects affecting ::gentoo discussed on regular mls?

2019-06-26 Thread Benda Xu
Dear Michał, Michał Górny writes: > I would like to ask our this year's GSoC mentors a single question: > why weren't the GSoC proposals given proper discussion on our regular > mailing lists *before* they were accepted? > I can understand that most developers in Gentoo don't really care about

Re: [gentoo-dev] RFC: BLAS and LAPACK runtime switching

2019-05-29 Thread Benda Xu
Hi David, David Seifert writes: >> > An actual ABI compliance test, e.g. done using abi-compliance- >> > checker would be more interesting. >> >> As said above, the symbols don't need to be 1-1 copy of each other. >> Any library which is a superset of the reference one will work. > > Again,

Re: [gentoo-dev] RFC: BLAS and LAPACK runtime switching

2019-05-29 Thread Benda Xu
Hi Michał, Michał Górny writes: > On Tue, 2019-05-28 at 01:37 -0700, Mo Zhou wrote: >> Different BLAS/LAPACK implementations are expected to be compatible >> to each other in both the API and ABI level. They can be used as >> drop-in replacement to the others. This sounds nice, but the

Re: [gentoo-dev] RFC: BLAS and LAPACK runtime switching

2019-05-29 Thread Benda Xu
Dear David, David Seifert writes: > We already have such a solution in the sci-overlay. It has proven > extremely brittle and shaky. What's more, using eselect set which library to link to was regarded harmful. > The plan is to do this via USE flags similar to python-single-r1 > flags. Yes,

Re: [gentoo-dev] [PATCH] Eclass changes for cross-compiling Python modules

2019-01-03 Thread Benda Xu
Hi James, James Le Cuirot writes: > Once this is in place, I can finish my long-awaited revamp of my > cross-boss project that will allow you to cross-compile @system from > scratch with very little effort. I haven't gone through the patches yet. But I want to say thank you! The cross-boss

[gentoo-dev] Re: netsurf Prefix breakage

2018-11-26 Thread Benda Xu
OK Virgil, Virgil Dupras writes: > Discussing this change on the list? I haven't touched the eclass, I > simply fixed the xmw-abandoned netsurf package which had been broken for > 3 months prior to that (and by broken, I don't mean only on Prefix. Why > talk about 1-1 features in those

netsurf Prefix breakage (Was: [gentoo-dev] Packages up for grabs from xmw@g.o)

2018-11-26 Thread Benda Xu
Hi Virgil, Virgil Dupras writes: > I've been getting rid of netsurf.eclass' usage. This can soon be > last-rited. Only two-stabilizations away from that goal. I am sorry to raise this, but your migration of netsurf.eclass into dev-util/netsurf-buildsystem is not a 1-1 feature copy of the old

[gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs from xmw@g.o

2018-11-25 Thread Benda Xu
Michał Górny writes: > x11-wm/xpra I take this, the "X Persistent Remote Apps". Benda signature.asc Description: PGP signature

Re: [gentoo-dev] [RFC] Removing support for mercurial repos in repositories.xml

2018-09-23 Thread Benda Xu
Michał Górny writes: > If you noticed that Gentoo repository mirrors did not update for 10 > hours a few days ago -- Mercurial was the reason. It is very fragile, > and if some server chokes during sync, it hangs the whole process until > somebody (which means me) kills it. And it's not the

[gentoo-dev] RFC: removal of keyword arm-linux

2018-08-26 Thread Benda Xu
Hi, As the Perl Team raised the issue of "arm-linux" keywords in the ebuilds[1], I think it is a good chance to completely remove them from our tree. What is "arm-linux" keyword? Gentoo Prefix has 2 kinds of profiles. An libc profile builds glibc in a Prefix and uses implicit keywords, while

Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-26 Thread Benda Xu
Thanks Ben, Ben Kohler writes: > To stay on the original track, I was suggesting adding it to the linux > profile component, not base. And people who are unwilling to use udev > would disable it globally, like people who are unwilling to use pam or > ipv6. > > But I understand where you're

Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-26 Thread Benda Xu
Hi Rich, Rich Freeman writes: > I don't believe anybody suggested making Gentoo harder to customize. > This is just about setting reasonable defaults. > > You can run a server without bash, openrc, sysvinit, or glibc. Should > these also be removed from the base profile? A reasonable default

Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-20 Thread Benda Xu
Hi Mart, Mart Raudsepp writes: > That said, I would question such a choice. Does it technically not > work or what's the problem with it? It works partially. Most of the time they does not bulid. The host OS handles /dev for Gentoo Prefix, be it mdev or udev. > But it's up the prefix

Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-19 Thread Benda Xu
Hi Ben, Ben Kohler writes: > I'd like to propose adding USE=udev to our linux profiles (in > profiles/default/linux/make.defaults probably). This flag is already > enabled on desktop profiles but it also affects quite a few packages > used on non-desktop linux systems. > > This flag provides

Re: [gentoo-dev] Gentoo QA Scripts

2018-06-08 Thread Benda Xu
Hi Michael, Michael Mair-Keimberger writes: > Some time ago i presented some scripts which are running daily on my > website to provide some basic QA findings. I wanted to give you a > update on the status of the scripts as many things changed since then. > First of all, gentoo.levelnine.at is

Re: [gentoo-dev] understanting gentoo

2018-03-24 Thread Benda Xu
Abhishek, Abhishek Kumar writes: > I want know about code that exist in gentoo/gentoo > which parse the command eslect news. > Please respond as soon as possible. A classic by Eric Raymond and Rick Moen on how to ask questions the smart way:

Re: [gentoo-dev] Mailing list moderation and community openness

2018-03-22 Thread Benda Xu
Hi Rich, Rich Freeman writes: > Actually, I think it is more of a technical constraint. It is > basically impossible to blacklist somebody on a mailing list, since > all they need to do is roll up a new email address. > I can think of various arguments for whitelisting or

[gentoo-dev] Pypi generator (Was: [RFC] Begin a dev-libs/nodejs category?)

2018-03-21 Thread Benda Xu
X dej writes: > I did not find anything wannabe "g-pip" for python. Check out app-portage/gs-pypi.

Re: [gentoo-dev] Fwd: understanding gentoo

2018-03-20 Thread Benda Xu
Abhishek, Abhishek Kumar writes: > -- Forwarded message -- > From: Abhishek Kumar > Date: Tue, Mar 20, 2018 at 12:48 PM > Subject: understanding gentoo > To: gentoo-dev@lists.gentoo.org > > Hi Everyone > > I want to know the

Re: [gentoo-dev] Mailing list moderation and community openness

2018-03-20 Thread Benda Xu
William Hubbs writes: > I do feel that this decision reflects badly on us as a community and > should be reversed immediately. The proper way to deal with people who > have bad behavior is to deal with them individually and not put a > restriction on the community that is

Re: [gentoo-dev] [RFC] Begin a dev-libs/nodejs category?

2018-03-20 Thread Benda Xu
Hello Herb, "Herb Miller Jr." writes: > When I did my homework on creating nodejs ebuilds (not nodejs itself > but packages written in node), it seems the topic has come up a few > times in the past but the time commitment and general disorganization > of upstream has

Re: [gentoo-dev] things becoming better and better

2018-03-19 Thread Benda Xu
Hi Toralf, Toralf Förster writes: > When I started with my tinderbox 2 or 3 years ago I had often a fair > amount of manual work to made to get an image up and running - moslty > tweaking USE flags to get blockers being solved. This yielded into a > growing list of fixed USE

Re: [gentoo-dev] Integrating Portage with other package managers

2018-03-11 Thread Benda Xu
Hi anoteros, anote...@teknik.io writes: > Having used Gentoo for a few years now, one thing that has been > annoying to me is the tremendous duplication of effort and uphill > battle of creating ebuilds (build recipes) for language-specific > packages that already have their own build systems. >

Re: [gentoo-dev] Functional portage with namespace

2018-03-11 Thread Benda Xu
Hi Xdej, X dej writes: > If you want to have reproducible binaries, you may also want to alter > the clock of the sandbox system. Ha, indeed many packages hardwrites "date of build" alike. That is a hard question to define reproducibility. I would

[gentoo-dev] Functional portage with namespace (Was: Integrating Portage with other package managers)

2018-03-08 Thread Benda Xu
Rich Freeman writes: > If you have util-linux installed then try running (as any user - you > don't have to be root): unshare -i -m -n -p -u -C -f --mount-proc -U > -r /bin/bash > > Congrats. You are now root in a container. You're in the same root > filesystem as always.

Re: [gentoo-dev] Integrating Portage with other package managers

2018-03-07 Thread Benda Xu
Hi Folks, Michael Orlitzky writes: > These other package managers don't solve any hard problems -- they're > basically a fancy interface around wget and "git clone." Portage on the > other hand has ~20 years of good ideas and hard work on the hard > problems in package

Re: [gentoo-dev] Integrating Portage with other package managers

2018-03-07 Thread Benda Xu
Dear Rich, Rich Freeman writes: > Everybody I know has these sorts of complaints about language-based > PMs, whether they prefer Ubuntu, or Debian, or CentOS, or whatever. > Nobody wants random programs downloading random stuff and dropping > orphan files all over their

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

2018-03-03 Thread Benda Xu
Hi Andreas, "Andreas K. Huettel" writes: > Well, in principle the idea is OK. We already/still keep some old > glibc, gcc, and binutils versions for that reason. > > However, I have a few conditions. > > * Only masked. Only prefix keywords. Not problem for masking. For

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

2018-03-03 Thread Benda Xu
Hi Michał, Michał Górny writes: >> I am on the toolchain alias, and I am interested in joining the project. >> I will be responsible to deal with all the bugs for glibc-2.16 and >> glibc-2.19. Bug wranglers' work load does not change. >> >> Yes, I apologize this will

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

2018-03-03 Thread Benda Xu
Hi Andreas, I really appreciate your interest as I am try to convince our fellows. "Andreas K. Huettel" writes: > another option would be to (try to) revive glibc-2.5, 2.12, and 2.17 > instead. > Yes I know they are even older, but these are the versions that RHEL >

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

2018-03-03 Thread Benda Xu
Hi Michał, Michał Górny writes: >> I am sure you are aware that Prefix has two variants: one is >> prefix-rpath targeting MacOS, Solaris, AIX, Cygwin, Interix and a subset >> of GNU/Linux; the other is prefix-standalone, targeting GNU/Linux and >> Android/Linux.[1] >> >> For

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

2018-03-03 Thread Benda Xu
Hi William and Alec, Yes, I hear you. What I want to do is not randomly throwing upstream-unmaintained package versions into Gentoo tree. But the opposite, 1 specially maintained glibc ebuild serving as a compatible layer will isolate the obsolete linux kernel from the modern Gentoo tree.

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

2018-02-25 Thread Benda Xu
Hi Michał, Michał Górny writes: > I don't think this is the first old version Prefix team needs keeping. > Another example are old versions of LLVM. I am sure you are aware that Prefix has two variants: one is prefix-rpath targeting MacOS, Solaris, AIX, Cygwin, Interix and a

Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

2018-02-25 Thread Benda Xu
Hi Michał, Michał Górny writes: >> So I would like to hear what you guys think if I: >> >> - keep glibc-2.19 and glibc-2.16 in tree and unmasking them in the >> selected Prefix profiles; >> >> - maintain those selected outdated glibc versions on the >>

[gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels

2018-02-24 Thread Benda Xu
Hi all, Yes, it's 2018. But there are still RHEL 4 and 5 systems running antique kernels such as 2.6.8 and 2.6.18. In my experience, many of them are data acquisition hubs or computing clusters. No administrator cares about security as long as they "work". Under the form "Prefix", Gentoo is

Re: [gentoo-dev] SAT-based dependency solver: request for test cases

2018-02-17 Thread Benda Xu
Hi Michael, I haven't fully understood SAT yet and I haven't completely follow the discussion. But I think this is a logical direction to improve dependency solving in Gentoo. Keep on the good work, I am interested in knowing how well it performs. Yours, Benda

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

2018-02-17 Thread Benda Xu
Hi William, William Hubbs writes: > The second change is that baselayout is taking ownership of most of the > directories it creates. This includes all directories in / and /usr > excluding /lib* and /usr/lib*. Once we drop support for SYMLINK_LIB, > baselayout will take

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

2018-02-17 Thread Benda Xu
Hi William, William Hubbs writes: > here is a link to an old, but brief discussion about this. > > https://archives.gentoo.org/gentoo-dev/message/2fc1f62c7cf225787fe52f4dace7368c > > I think we have talked about this several other times, but not done > anything about it. >

Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

2018-01-15 Thread Benda Xu
Hi, R0b0t1 writes: > I have seen similar choices made before, but this is the first time I > have seen a good case for the choice you selected. E.g.: > > (Current.) > *> >*=> > *==> >

Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

2018-01-12 Thread Benda Xu
Hi Patrice, Patrice Clement writes: > Thanks for the work. > > Could you also consider adding a Prefix profile compatible with > FreeBSD? We have supported BSD before. But at the moment, no one on the Prefix team have access to BSD hosts. Historically, fauli has

Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

2018-01-12 Thread Benda Xu
Hi R0b0t1, R0b0t1 writes: > I don't want to just comment on naming, but: > > It might be more natural to go the other way. Split profiles off based > on version when breakage occurs, and otherwise do not reference a > specific version. > > Then, the name indicates the most

[gentoo-dev] Re: [gentoo-dev-announce] Upcoming posting restrictions on the gentoo-dev mailing list

2018-01-10 Thread Benda Xu
Hi, "Andreas K. Huettel" writes: > If, as a non-developer, you want to participate in a discussion on > gentoo-dev, > - either reply directly to the author of a list mail and ask him/her to > forward your message, With this item in mind, shall we set the default

Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

2018-01-10 Thread Benda Xu
Hi MJ, "M. J. Everitt" writes: > Not entirely as a #gentoo-nit-pick .. I'm slightly unclear on the > different between 2.6.16+ and 2.6.32+ .. should this potentially be > 2.16.16-32 perhaps [2.6.16~32 even] or is this more obvious only to me, > and more confusing to

Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

2018-01-08 Thread Benda Xu
Hi Aaron, Aaron Bauman writes: > I am not too familair with prefix other than the purpose of it (e.g. I > have never built it), but is there a better naming standard for the > profiles? I understand the need to distinguish between the kernel and > glibc versions. > Is there a

Re: [gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

2018-01-08 Thread Benda Xu
Hi kuzetsa, kuzetsa writes: > The term "beyond" feels wrong & confusing. > (Not sure what to replace it with though) How about this? default/linux/amd64/17.0/no-multilib/prefix/kernel-3.2+ default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.32+

[gentoo-dev] [PATCH] introduce Prefix 17.0 profiles.

2018-01-08 Thread Benda Xu
Hi, I would like to introduce some 17.0 profile for Prefix. It also introduces separate profiles to support different ranges of linux kernels. | name | linux| glibc | |--+--+---| | beyond-kernel-2.6.16 | [2.6.16, 2.6.32)

Re: [gentoo-dev] Eclasses for BLAS and Lapack

2017-12-04 Thread Benda Xu
Dear Fellows, and thanks Dominik, Dominik Schmidt writes: > Gentoo does not yet have a (proper) way of selecting a BLAS or Lapack > implementation at compile time. Hence I wrote two eclasses, which can > be found in my fork of the science overlay: > > *

Re: [gentoo-dev] Re: [RFC, PATCH] user.eclass: gracefully return when unprivileged

2017-11-25 Thread Benda Xu
Fabian Groffen writes: > I think we could definitely live with this until someone requests > otherwise. Indeed. Committed, thanks a lot! Benda signature.asc Description: PGP signature

Re: [gentoo-dev] [RFC, PATCH] db.eclass: support Prefix

2017-11-25 Thread Benda Xu
Committed, thanks a lot! Benda

Re: [gentoo-dev] Re: [RFC, PATCH] user.eclass: gracefully return when unprivileged

2017-11-25 Thread Benda Xu
Hi Patrick, Patrick McLean writes: > I use portage as non-root all the time when developing and testing > ebuilds, via the "ebuild" command. The enewgroup and enewuser are used in pkg_* functions, as documented in user.eclass _assert_pkg_ebuild_phase() function. They

[gentoo-dev] Re: [RFC, PATCH] user.eclass: gracefully return when unprivileged

2017-11-21 Thread Benda Xu
Francesco Riosa writes: > maybe ewarn() is more appropriate than einfo()? > Just in case it's executed outside the scope of prefix I can't remember any use case when portage (or, paludis, etc.) is executed as a normal user but not a from Prefix. This message will only affect

[gentoo-dev] Re: [RFC, PATCH] user.eclass: gracefully return when unprivileged

2017-11-21 Thread Benda Xu
Francesco Riosa writes: > maybe ewarn() is more appropriate than einfo()? > Just in case it's executed outside the scope of prefix I can't remember any use case when portage (or, paludis, etc.) is executed as a normal user but not a from Prefix. This message will only affect

Re: [gentoo-dev] Re: Prefix bootstrap script maintainability

2017-11-20 Thread Benda Xu
R0b0t1 writes: > This is why I am surprised documentation is lacking for specific > projects, or, I suppose, any software package that has ever been > created. No surprise. There is always a gap between theory and practice. That said, I will prioritize myself to document

Re: [gentoo-dev] NEWS item for games destabling

2017-11-19 Thread Benda Xu
David Seifert writes: > As the Games team does not have enough manpower to keep tabs on all > games packages, we have dropped all games-* ebuilds to unstable > KEYWORDS (modulo those required by stable non-games packages). "modulo" is too mathematical to be

[gentoo-dev] Prefix bootstrap script maintainability (Was: No more stable keywords for Games)

2017-11-19 Thread Benda Xu
Greetings R0b0t1, R0b0t1 writes: > It is one thing to say that contributions to the main Portage tree > require some standards to be upheld, but these standards do not seem > to be applied consistently. For example, crossdev, genkernel, and the > bootstrap-prefix and

[gentoo-dev] OpenJDK bootstrap (Was: Java 9 on Gentoo)

2017-11-18 Thread Benda Xu
Hi Roy, Roy Bamford writes: > You can start with gcc-5.4 with the gcj use flag. That will bootstrap > icedtea:7 icedtea:7 will bootstrap icedtea:8 Tested on arm64. Have my respect. It answers the question lurking in my mind for years. This opens the possibility to

Re: [gentoo-dev] Re: New SYMLINK_LIB=no migration tool for review

2017-08-02 Thread Benda Xu
"Walter Dnes" writes: > And what happens when 128-bit cpus debut? /lib128? In this case CHOST makes more sense. From my understanding, the Exherbo approach is the cleanest. Benda

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

2017-07-30 Thread Benda Xu
Hi, Sam Jorna writes: > Wouldn't it make more sense to make Gentoo *more* attractive to run in > corporate environments, rather than simply saying "We're not RHEL so why > bother"? > > People do use Gentoo in production environments, both personally and > professionally, even

Re: [gentoo-dev] dev-python/matplotlib needs a real maintainer

2017-06-21 Thread Benda Xu
Hi Mike, Mike Gilbert writes: > This is a fairly fragile/complex package, and it is specialized enough > that I don't think it belongs under the purview of the Gentoo Python > team. > > If you are interested in this package and want to maintain it, please > feel free. I will

[gentoo-dev] Re: [RFC] Restricted version of gentoo-dev mailing list

2017-05-23 Thread Benda Xu
Hi Michał, > Name: gentoo-dev-internal > > Topic: technical discussions between active Gentoo contributors Basically I object to this proposal. 1. Another layer of hierarchy is not desirable for a non-profit organization like us. 2. Useful discussion are diluted from 1 list into 2 lists.

Re: [gentoo-dev] RFC: Introducing stable profiles for arm64 (aarch64)

2017-02-06 Thread Benda Xu
Hi Mart, The Gentoo on Android project will directly benefit from the new stable profiles for 64bit smartphones and other mobile devices. I have been keywording ~arm64 here and there casually. It is very exciting to see such progress. Keep the good job. Cheers, Benda signature.asc

Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

2017-02-03 Thread Benda Xu
William Hubbs writes: > I have been looking at the meson build system [1] [2], and I like what I > see. > > I have opened an issue on OpenRC's github wrt migrating OpenRC to the > meson build system [3]. > > As I said on the bug, the downside is the addition of py3 and ninja

[gentoo-dev] [PATCH 4/7] toolchain.eclass: prefixify helper scripts.

2017-01-07 Thread Benda Xu
Directory prefixify part 2. --- eclass/toolchain.eclass | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass index 40759f5..17950c1 100644 --- a/eclass/toolchain.eclass +++ b/eclass/toolchain.eclass @@ -8,7 +8,7 @@

[gentoo-dev] [PATCH 7/7] toolchain.eclass: remove trailing slash of D.

2017-01-07 Thread Benda Xu
--- eclass/toolchain.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass index 941e37b..0d8148f 100644 --- a/eclass/toolchain.eclass +++ b/eclass/toolchain.eclass @@ -1727,7 +1727,7 @@ toolchain_src_install() { # Now

[gentoo-dev] [PATCH 6/7] toolchain.eclass: Quote variables containing EPREFIX.

2017-01-07 Thread Benda Xu
Directory prefixify part 4. LIBPATH, etc. now have EPREFIX prepended. The latter need to be quoted. --- eclass/toolchain.eclass | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass index

[gentoo-dev] [PATCH 1/7] toolchain.eclass: Call fix_libtool_files.sh by name

2017-01-07 Thread Benda Xu
/usr/sbin is in PATH, avoid writing ${EPREFIX}/usr/sbin/fix_libtool_files.sh. --- eclass/toolchain.eclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass index 55249b0..ef932d2 100644 --- a/eclass/toolchain.eclass +++

[gentoo-dev] [PATCH 5/7] toolchain.eclass: Prepend/strip EPREFIX.

2017-01-07 Thread Benda Xu
Directory prefixify part 3. Raw directories are prepended by EPREFIX. Directories passed to ebuild helpers are EPREFIX stripped. --- eclass/toolchain.eclass | 34 +- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/eclass/toolchain.eclass

[gentoo-dev] [PATCH 3/7] toolchain.eclass: D->ED ROOT->EROOT replacements.

2017-01-07 Thread Benda Xu
Directory prefixify part 1. In addition, E/D and E/ROOT has trailing slashes. No need to write an additional slash. --- eclass/toolchain.eclass | 29 +++-- 1 file changed, 15 insertions(+), 14 deletions(-) diff --git a/eclass/toolchain.eclass

[gentoo-dev] [PATCH 2/7] toolchain.eclass: drop env -i from gcc-config calls.

2017-01-07 Thread Benda Xu
In Prefix, PATH should also be preserved, resulting in a mouthful of `env -i PATH=${PATH} ROOT=${ROOT}`. The origin commit introducing env -i was for "cleanup". Dropping env -i is cleaner. Reference:

[gentoo-dev] [PATCH 0/7] RFC1: toolchain.eclass prefix support

2017-01-07 Thread Benda Xu
Hi, This patch series is splitted from the previous one https://archives.gentoo.org/gentoo-dev/message/8a7ac352cb047567309c70aaf7105305 Note that the splitting is not perfect when different kinds of updates happen in adjacent lines. Please review. Benda Benda Xu (7): toolchain.eclass

[gentoo-dev] Re: RFC: toolchain.eclass prefix support

2017-01-07 Thread Benda Xu
Mike Gilbert writes: > Regarding the PATH/gcc-config change, I'm thinking it would make more > sense to drop the env -i command than to add to he list of special > variables we pass through to it. All the env -i has been introduced in this commit by vapier in 2005:

Re: [gentoo-dev] RFC: toolchain.eclass prefix support

2017-01-07 Thread Benda Xu
James Le Cuirot writes: > Why? All the ebuilds using this eclass that I can find are at least > EAPI 4. Okay! I will remove this. Benda signature.asc Description: PGP signature

[gentoo-dev] RFC: toolchain.eclass prefix support

2017-01-07 Thread Benda Xu
Hi, Please help me review the patch attached. This patch has 5 main kinds of modifications to the eclass, * Define ED and EROOT for EAPI 0, 1 and 2. * Add ${EPREFIX} to ${PREFIX} and quote the variables. * Strip ${EPREFIX} if used with a ebuild helper. * call fix_libtool_files.sh by

Re: [gentoo-dev] Gcc 6 and Gcc 5 update

2016-12-11 Thread Benda Xu
gro...@gentoo.org writes: > I hope gcj will remain in (which I use not very often but regularly). There are no real > alternatived: pdfshuffle fails on many (otherwise normal) pdf files. +1 I am a regular pdftk user. Benda

Re: [gentoo-dev] Gcc 6 and Gcc 5 update

2016-12-11 Thread Benda Xu
Hi, "Walter Dnes" writes: > Are the gmp, mpc, mpfr, and isl libs included? According to the > "Support libraries" section at https://gcc.gnu.org/wiki/InstallingGCC They are managed by their own ebuilds. >> Alternatively, after extracting the GCC source archive, simply

Re: [gentoo-dev] Gentoo on Android stage3

2016-10-29 Thread Benda Xu
Rich Freeman writes: > Well, that would be a different approach, but I imagine you could > build for prefix-style install using something like Catalyst and > cross-compile. I have no idea how much tweaking that would require. > The main issue is that unless you use qemu you're

Re: [gentoo-dev] Gentoo on Android stage3

2016-10-29 Thread Benda Xu
Hi Michael, "M. J. Everitt" writes: >> No SD slot on Nexus. We will stress the internal NAND flash with >> millions of ebuilds and rsync :) > Completely out of my depth here, but can you cross-compile and Ah, I was half-joking. Considering the recent advancement of NAND

  1   2   >