Re: [gentoo-dev] [PATCH 1/2] rocm.eclass: Fix the xnack feature for gfx90a

2023-11-26 Thread Benda Xu
Hi Yiyang,

Yiyang Wu  writes:

> Upstream usually ships 2 version: gfx90a:xnack-, gfx90a:xnack+. Although
> a single gfx90a should have maximum compatibility, According to [1,2],
> compile with xnack+/xnack- may have better performance on xnack
> enabled/disabled GPUs. Therefore we ship both the target, align with
> upstream. gfx900 is also appended with :xnack- to align with upstream
> default.

> [1] https://llvm.org/docs/AMDGPUUsage.html#target-features
> [2] 
> https://docs.olcf.ornl.gov/systems/crusher_quick_start_guide.html#compiling-hip-kernels-for-specific-xnack-modes

So, you want to add a new ABI to gfx90a for experimental xnack feature.
I suggest make it gfx908a with gfx908a_xnack, instead of
"gfx908a_noxnack" for consistency the existing naming scheme.

With this minimal modification, the remaining cards such as gfx906 and
gfx908 that support xnack could be updated incrementally.

Benda



Re: [gentoo-dev] [PATCH] distutils-r1.eclass: Use gpep517's new prefix rewriting options

2023-08-23 Thread Benda Xu
James Le Cuirot  writes:

>   if [[ -n ${SYSROOT} ]]; then
> - cmd+=( --sysroot "${SYSROOT}" )
> + cmd+=(
> + --sysroot "${SYSROOT}"
> + --rewrite-prefix-from "${BROOT}"
> + --rewrite-prefix-to "${EPREFIX}"
> + )
>   fi

Looks good to me.  Thanks!

Yours,
Benda



[gentoo-dev] last rite sci-electronics/gwave

2023-07-31 Thread Benda Xu
# Benda Xu  (2023-08-01)
# Dead upstream. blocking guile-3 migration and gtk+-2 removal.
# Removal on 2023-09-01. (bug #824966)
sci-electronics/gwave



Re: [gentoo-dev] Gentoo - Google Summer of Code (GSoC)

2023-02-17 Thread Benda Xu
Dear Yury,

Yury German  writes:

> I am trying to follow up and see if anyone is interested in becoming a 
> mentor. 
>
> This is the last request I am sending as so far we only have two
> people willing to mentor and it is project dependent.
>
> Do we have any other volunteers as I want to make sure that we have a
> few mentors being able to mentor. At the current stage we will be
> unable to participate in this years GSoC if we are unable to get a
> bigger pool of potential mentors.
>
> There are only 2 days left. If you are interested please let me know ASAP. 

I have missed the 2-day deadline.  But I would like to mentor 1 project
this year.

Yours,
Benda



Re: [gentoo-dev] [PATCH 1/2] prefix.eclass: don't redundantly define EPREFIX as an eclass variable

2022-08-14 Thread Benda Xu
Sam James  writes:

> Since EAPI 3, EPREFIX has been defined via PMS. Having this as an
> "eclass variable" in docs is confusing as it implies one needs
> prefix.eclass to provide it.
>
> Drop it given it adds nothing and causes confusion.
>
> Reported-by: Aaron W. Swenson 
> Signed-off-by: Sam James 
> ---
>  eclass/prefix.eclass | 14 +-
>  1 file changed, 1 insertion(+), 13 deletions(-)
>
> diff --git a/eclass/prefix.eclass b/eclass/prefix.eclass
> index 8d50d0ba7b6e..4a8c0e4ff15f 100644
> --- a/eclass/prefix.eclass
> +++ b/eclass/prefix.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2021 Gentoo Authors
> +# Copyright 1999-2022 Gentoo Authors
>  # Distributed under the terms of the GNU General Public License v2
>  
>  # @ECLASS: prefix.eclass
> @@ -20,18 +20,6 @@ esac
>  if [[ -z ${_PREFIX_ECLASS} ]]; then
>  _PREFIX_ECLASS=1
>  
> -# @ECLASS_VARIABLE: EPREFIX
> -# @DESCRIPTION:
> -# The offset prefix of a Gentoo Prefix installation.  When Gentoo Prefix
> -# is not used, ${EPREFIX} should be "".  Prefix Portage sets EPREFIX,
> -# hence this eclass has nothing to do here in that case.
> -# Note that setting EPREFIX in the environment with Prefix Portage sets
> -# Portage into cross-prefix mode.
> -if [[ ! ${EPREFIX+set} ]]; then
> - export EPREFIX=''
> -fi
> -
> -
>  # @FUNCTION: eprefixify
>  # @USAGE: 
>  # @DESCRIPTION:

LGTM, thanks Sam!

Yours,
Benda



[gentoo-dev] Re: [PATCH 2/2] profiles/desc: add amdgpu_targets.desc for USE_EXPAND

2022-08-08 Thread Benda Xu
Yiyang Wu  writes:

> +gfx1010 - RDNA GPU, codename navi10, including Radeon RX 
> 5700XT/5700/5700M/5700B/5700XTB/5600XT/5600/5600M, Radeon Pro 5700Xt/5700, 
> Radeon Pro W5700X/W5700

s/5700Xt/5700XT/

Benda



Re: [gentoo-dev] Gentoo LLVM project needs help!

2022-02-11 Thread Benda Xu
Michał Górny  writes:

>> > 6. Work on setting up and configuring a buildbot for Gentoo LLVM builds.
>> > This is some effort and I don't have the time to learn how to do that. 
>> > You'll probably need to set up a local instance and figure out how to
>> > set our builds before submitting anything upstream; in my experience
>> > they aren't very responsive to buildbot changes, so ideally we need to
>> > flesh out any problems early.
>> 
>> GSOC-worthy project?
>
> Not sure.  To rephrase what was once said to me, this is summer of
> *code*, not infra work.

If infra work means writing batch scripts to drive build bots, automate
tasks, generating reports and sending email notifications, it fits
summer of code.

Writing configurations is programming with descriptive DSLs.



signature.asc
Description: PGP signature


[gentoo-dev] Re: [RFC] Un-slotting LLVM

2021-11-09 Thread Benda Xu
Hi Michał,

Michał Górny  writes:

>> [...]
>>
>> Unfortunately, this ended up pretty bothersome to maintain.  Besides
>> making ebuilds quite complex (and prone to mistakes), I'm hearing more
>> and more reports of programs being broken through getting multiple LLVM
>> versions in the link chain.
>> 
>> This is not something that can be easily solved.  In other words, it's
>> a mess and I don't think we're really getting anywhere.  For this
>> reason, I'm considering dropping slotting and going back to permitting
>> only a single version of LLVM and Clang being installed.
>> 
>> [...]
>
> I've got the message and slotted LLVM and Clang are going to stay for
> the time being.

Thank you!  I appreciate your decision.  From the discussions of this
thread, the quality and SLOTing of llvm is a killing feature of Gentoo.

Shall we open a tracker bug to put together the linkage bugs?  We might
gain some inspirations from the global picture.

Yours,
Benda


Re: [gentoo-dev] Gentoo 18th Anniversary Edition - Help Needed

2021-04-19 Thread Benda Xu
Roy,

Roy Bamford  writes:

> Its my 18th anniversary of installing Gentoo. A number of coincidences gave 
> rise to
> my original liveCD turning up when I was searching for bits to get an old 
> system to boot
> just one more time to get some forgotten data off its hard drives. I just had 
> to try it out.
>
> Anyway, one thing lead to another and now I have a 2003 Gentoo install as a 
> Virtualbox
> guest https://wiki.gentoo.org/wiki/User:NeddySeagoon/Historical_Gentoo all 
> except 10 
> files. It boots, GNOME and KDE run, it won't play blurays but it has a few 
> bits missing,
> so its not quite original. 
>
> Here's where I reed your help. The missing distfiles are
>
> MD5 0d9151faa28fcbdff6b37559ce4895f5 kdegraphics-3.1.1a.diff.bz2
> MD5 38adc94a4953a6b29e8619c25dda4887 4.2.0-4.2.1.diff.gz 54763
> MD5 43e5e0209a9400b946f38d7c731c968c sis_drv_src_210303-1.tar.gz 378880
> MD5 45133b34f10632f3ffc012401e2a4b19 util-linux-2.11y-crypt-gentoo.patch.gz 
> 18843
> MD5 4d84dd6a0f00d84850f2765766c6b780 kdebase-3.1.1a.diff.bz2
> MD5 50891a2431cc829d98829e385e2c452c XFree86-4.2.1-patches-1.2.tar.bz2 405424
> MD5 5687b1f9d7e0698f63c35c53322c786a kdelibs-3.1.1a.diff.bz2
> MD5 6dc1978d748dc6519933743b0337f718 pam_login-3.10.tar.bz2 131130
> MD5 aaeb8f8b276a6849f7a570097d69788e glide3-headers.tar.bz2 14564
> MD5 d5cc6a93c7d3ad2eb02bc637a1de9cf3 net-tools-1.60-gentoo-extra.tar.bz2 5785
>
> If your Gentoo history goes back as far as mine and you still have those 
> files, please
> share them with me. 

I regret that I did not understand GNU/Linux back in 2003 to help you.
This is indeed a cool project to celebrate your 18th anniversary of
Gentoo ;)  Please share some videos after you finish that.

Benda


signature.asc
Description: PGP signature


Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390

2021-02-09 Thread Benda Xu
Hi Michał,

Michał Górny  writes:

> So it seems that upstream has practically closed the discussion,
> and the short summary is that they only care for the 'majority' of
> users, they don't care for minor platforms (but we're free to port
> LLVM/Rust to them) and -- unsurprisingly -- this is a part of crusade
> towards promoting Rust.
>
> Given the aggressive opinions of a number of Python core devs
> participating in the discussion, I'm afraid that it is quite probable
> that a future version of CPython may require Rust.  In fact, they've
> already started having knee-jerk reactions to the problem at hand [1]. 
> To be honest, I've never thought I'd be this disappointed in Python
> upstream.
>
> Good news is that they've promised to keep a LTS branch with security
> fixes to the non-Rust version.  Until end-of-year.  And they've pretty
> aggressively stated that they won't fix anything except security bugs
> with a CVE assigned.  So if it stops building for whatever reason, we're
> on our own.
>
> I've reached out to Debian and they're planning to remove support for
> minor architectures for this package in the next release.  However,
> Python is not as central to them as it is to us.  Alpine is also
> affected but seems intent on pushing Rust forward, so they'll probably
> drop these architectures as well.
>
> Mike's submitted a PR to remove (unnecessary) cryptography dep from our
> urllib3/requests packages [2].  This should make it possible to avoid
> cryptography at least on some systems.  However, it is still an indirect
> test dependency of these packages, so we're going to have a hard time
> keeping them properly tested.
>
> At this point, I'm really depressed about this and I'm seriously
> wondering why I'm wasting so much effort on open source.  I don't see
> a good way out of it.  Rust could be a nice language -- but it won't if
> it continues to be surround by arrogant zealots who want to destroy
> everything in their path towards promoting it.
>
> The first big blocker we're going to hit is trustme [3] package that
> relies on cryptography API pretty heavily to generate TLS certs for
> testing.  If we managed to convince upstream to support an alternate
> crypto backend, we'd be able to retain minor keywords a lot of packages
> without too much pain.

I could feel the pain.  

Bootstraping Rust on Prefix is somewhere between alpha, hppa, ia64,
m68k, s390 and amd64[1].  The problem was exposed by
gnome-base/librsvg[2].

I am wondering how useable pkgcore is on alpha, hppa, etc.  Maybe it's
time for us to plan for a Gentoo without essential Python dependency.

Looking forward to gcc-rust for saving the world in the end.

Benda

1. https://bugs.gentoo.org/689160
2. https://bugs.gentoo.org/739574


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 to the Gentoo default a good
idea. One person who get stuck with udev does not bring everyone to
stick with udev.

Benda


signature.asc
Description: PGP signature


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 primarily by one person the last time I checked, and I
>  don't really know what he has included or not included from udev. What
>  I can say is that the last release of eudev hit the tree a year ago,
>  and I'm not sure about feature parity with udev.

What feature do you miss from systemd-udev that has been added within a
year?

udev should be a stable part of the system, I would rather have new
Gentoo users install something stable by default than a moving target.

Benda


signature.asc
Description: PGP signature


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
> that is still garnering any interest from gentoo?

There is still interest in Gentoo.  But no one seems to have energy to
take care of it.  Your contribution is welcomed.

> Would love to know if it could be possible in anyway.

Benda


signature.asc
Description: PGP signature


[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 idea.  What's your plan to realize the eclasses?


BTW, additional reference:
https://wiki.gentoo.org/wiki/Gentoo_Java_Packing_Policy

Yours,
Benda


signature.asc
Description: PGP signature


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 Java Developer Guide of Gentoo[1]?  If so, let's base
our discussion on what we have.

> [...]

Benda

1. https://wiki.gentoo.org/wiki/Java_Developer_Guide


signature.asc
Description: PGP signature


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
>>   capabilities.  Exit gracefully with a message.
>
> Please don't add this weird indent.

OK, thanks for pointing out.  Didn't notice that.

Benda


signature.asc
Description: PGP signature


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 handle correctly which lead to broken ebuilds
> and maintenance headaches. Speaking for python, catching and
> correcting the use of setup_requires and other insanity visited upon
> us by the wonders of setuptools makes this a non-starter. 

Yes, I agree.

> If you have a set a known sane packages you could in theory write an
> eclass that captures the regularities of those packages, but I'm not
> sure eclasses are suggested for that use case.

eclass is designed for eliminating duplicated code in ebuilds. Therefore
yes, it is the legitimate use of eclass.

Benda


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 possible in all cases? I think of adding custom patches,
> appropriate mapping of dependencies, check for things like desktop
> icon cache...

That's too complex to handle automatically.  Luckily, in R overlay, such
packages are less than 5%.  An ebuild generator is based on the
observation that many language-specific packages are trivial to fetch,
compile and install.

>> > I'm only "maintaining" an overlay so maybe I'm  missing experience
>> > but I often have wished a tool that automatically parses the language 
>> > specific
>> > packaging files and is able to generate a primitive ebuild out of that.
>> > Maybe it even can do this in an interactive way:
>> > "Hey, upstream needs the dependency 'foo'. In the Gentoo packages I have 
>> > found
>> > 'dev-bar/foo' and 'dev-util/foo'. What is the correct one?"
>> 
>> Yes, that's the way R overlay is working.  And I have a similar plan and
>> proof-of-concept solution for the Java Maven overlay.
>
> Nice to hear. I think, it is meaningful to solve all generation with one
> tool. Maybe it can even "recognize" the used build system and package
> database. Is this your plan, too?

No, I don't think it possible as far as I can see...  That would be a
strong AI.

Yours,
Benda


signature.asc
Description: PGP signature


[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: a really cool project but not used at a
> large scale.

Yes, that's true.  I share the same observation and concern with you.

This is one exception: the CRAN ebuild generator powered R overlay has
been running well for 8 years.

  https://wiki.gentoo.org/wiki/Project:Science/Overlay/R

> What do you think of the idea to not do this fully automated but supervised
> by a maintainer? With that I mean an ebuild generator that generates only
> the parts of the ebuild that it can easily parse and then present the ebuild
> draft to a maintainer who completes it to an full ebuild. As far a I know no
> tool like this exists. I think the focus shift helps a lot:
> Developing a tool for the Gentoo maintainer not the Gentoo user.

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.

> I'm only "maintaining" an overlay so maybe I'm  missing experience
> but I often have wished a tool that automatically parses the language specific
> packaging files and is able to generate a primitive ebuild out of that.
> Maybe it even can do this in an interactive way:
> "Hey, upstream needs the dependency 'foo'. In the Gentoo packages I have found
> 'dev-bar/foo' and 'dev-util/foo'. What is the correct one?"

Yes, that's the way R overlay is working.  And I have a similar plan and
proof-of-concept solution for the Java Maven overlay.

> With a not fully automatic tool also packages can be parsed that are not
> in a complete closed ecosystem, like a 'meson.build' file or cmake files for
> C++/C programs. But of course package databases like Maven/Cargo/Pypi are
> also candidates.
>
> Unfortunately, I have no time currently to participate in the GSOC. I just
> want to mention this here as an idea. Please comment or correct me, if
> such a tool already exists.

Thank you!  Your input is really valuable.

Yours,
Benda


signature.asc
Description: PGP signature


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 interested to join Gentoo and helping out.
>
> [...]

This year's GSoC organization application deadline is on Feb 5.  The
more project ideas, the better Gentoo will show itself to be prepared.
If you have been thinking of adding projects to our GSoC 2020 list, this
is a good chance to do so.

Cheers,
Benda


signature.asc
Description: PGP signature


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 interested to join Gentoo and helping out.
>
> [...]

Gentoo has receive high quality contributions in the past.  I hope this
year we could have attract more talented Google Summer of Code students
to work with us.

Cheers,
Benda


signature.asc
Description: PGP signature


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.
dev-python/qtconsole, a dependant of dev-python/ipython, still supports
python-2.7.  When qtconsole get emerged with
USE="python_targets_python2_7 python_targets_python3_6" for example, old
dev-python/ipython-5.8.0-r1 is drawn, resulting in conflict against
dev-python/ipython-7.5.0.  USE=python_targets_python2_7 had to be
removed from dev-python/qtconsole to avoid it.

If one package drops python-2.7, all its dependants have to drop
python-2.7 even if they can work with python-2.7.


Given the python-2 countdown deadline being 2020-01-01, a month away,
shall we get rid of python-2?


If the answer is yes, we will need to decide on the following
python-2-only packages.

,
| $ comm -23 <(equery -qC h python_targets_python2_7 | sort ) <(equery -qC h 
python_targets_python3_6 | sort) 
| dev-lang/yasm-1.3.0
| dev-libs/libxslt-1.1.33-r1
| dev-python/backports-functools-lru-cache-1.5
| dev-python/enum34-1.1.6-r1
| dev-python/functools32-3.2.3
| dev-python/futures-3.2.0
| dev-python/pygobject-2.28.6-r55
| dev-python/pygtk-2.24.0-r4
| dev-python/subprocess32-3.2.7
| dev-util/boost-build-1.70.0
| dev-vcs/subversion-1.12.2
| gnome-base/libglade-2.6.4-r2
| net-analyzer/nmap-7.70
| sys-devel/clang-8.0.1
| x11-wm/xpra-2.4.3
`

If the answer is no, to avoid holding back new versions having only
python3, such as bug 671796 for dev-python/matplotlib bump, old versions
with python_targets_python2_7 and new versions without should be
co-installable into different SLOTs.

What do you think?

Yours,
Benda



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 loaded into it necessary
> to accomplish this task.  The fact that the userland, in the current
> ill-conceived case, cannot get itself up and running simply because /usr is
> on a yet-to-be-mounted partition is not a concern of the kernel's.  Thus,
> the loading of an initramfs into the kernel to solve this issue is, in
> principle, a violation (and a Cthulhu-awful hack).
>
> Maybe I'm just a old codger who refuses to accept change.  I'm fine with
> that description.  I like things to remain somewhat simple, and my view of
> Linux, both kernel and userland, over the last few years is one of growing
> dismay due to the constant introduction of subsystem layer atop subsystem
> layer for very little gain.  How much longer until we need a kernel to boot
> the kernel to mount the userland that mounts the userland (yo dawg)?

This a very well put argument that I find enjoyable reading.  Thank you
Joshua.

Yours,
Benda



[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 means that I've finally retired that ugly hack that split
> categories into multiple groups and ran them in parallel.  This means
> that CI is no longer bound by the longest category (hello, media-libs/)
> and can utilize all 32 cores instead of ~14.
>
> This also means that if you're planning to run tree-wide scans with
> pkgcheck, you no longer have to employ huge hacks to make them faster. 
> You just run it normally!  In your face, repoman!
>
> Once again, thanks to radhermit.  His work on pkgcheck is astonishing,
> and it's becoming a great tool for developers.

A big round of applause to radhermit for the better QA tool!

Thank you to all who contributed.

Benda


signature.asc
Description: PGP signature


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 always ${SYSROOT}${EPREFIX}. We
>> > therefore cannot do it! If the crossdev prefix is blank then ROOT's
>> > must be blank too.  
>> 
>> My question: is there a case when both SYSROOT and ESYSROOT are needed?
>> As far as I can see, SYSROOT is strictly build-time. Therefore setting
>> SYSROOT= would be enough for all.
>> 
>> Why did ESYSROOT exist in the first place?  Was it only for the sake of
>> symmetry, or did I miss something?
>
> Remember that we now install packages to SYSROOT too. Portage needs to
> know the prefix so that it can set EPREFIX when building these
> packages. You'll already know that you can't fake EPREFIX by setting
> ROOT. We could potentially work out EPREFIX by comparing SYSROOT with
> BROOT and EROOT (instead of / and ROOT) but that's not the whole story.
>
> When using crossdev, pkg-config files are sourced from SYSROOT. These
> may return paths like -L/myprefix/usr/lib. If SYSROOT!=/ then
> pkg-config will need to translate this to -L/myroot/myprefix/usr/lib.
> However, it's bad to explicitly add lib and include paths that the
> toolchain would look at anyway as it can change the search order. Under
> a regular setup, pkg-config would omit -L/usr/lib -I/usr/include but for
> this to work in the above setup, we need to know that /myprefix is a
> prefix. As stated, we don't have an explicit variable for SYSROOT's
> prefix but we can work it out using ${ESYSROOT#${SYSROOT}}. This is
> what I have done in my pending cross-pkg-config fixes.
>
> None of that magic happens when not using crossdev. I have debated
> whether it should but native builds with SYSROOT!=/ tend to be a
> disaster for various other reasons so perhaps it's not worth worrying
> about.
>
> There are probably more reasons when we need to know the prefix but I
> can't remember what they are now. :)

I could only remotely understand your argument.  But I feel you know
what you are doing.  So go ahead.

And please excuse me if I raise this again in the future.

>> In conclusion, IMHO, if SYSROOT can be overridden without restriction
>> ("distinct" in your email), we could cover all the use cases.
>
> It's still a little bit restricted but less than it was and the only
> cases we don't handle are obscure ones that we wouldn't want to support
> anyway.
>
> When dealing with this stuff, it's worth remembering that practically no
> one has used crossdev with prefix until recently. I know this because
> I had to fix the glibc ebuild, Portage, and crossdev itself to make it
> work following a bug report this month. ;)

That is an heroic effort.

I have tried to bring together crossdev and Prefix together in the past
but found too many obstacles to achieve it.

Thank you a million times!

Yours,
Benda


signature.asc
Description: PGP signature


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: Michał Górny 
> ---
>  eclass-to-manpage.awk | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/eclass-to-manpage.awk b/eclass-to-manpage.awk
> index 44708d4..f8620c8 100755
> --- a/eclass-to-manpage.awk
> +++ b/eclass-to-manpage.awk
> @@ -33,6 +33,7 @@
>  # @MAINTAINER:
>  # 
>  # [@INTERNAL]
> +# [@INCLUDES_EPREFIX] (the function outputs path that includes ${EPREFIX})
>  # @DESCRIPTION:
>  # 
>  
> @@ -42,6 +43,7 @@
>  # [@INTERNAL] (internal eclass use variable)
>  # [@DEFAULT_UNSET]
>  # [@REQUIRED]
> +# [@INCLUDES_EPREFIX] (the variable is a path that includes ${EPREFIX})
>  # @DESCRIPTION:
>  # 
>  # foo=""
> @@ -54,6 +56,7 @@
>  # [@INTERNAL] (internal eclass use variable)
>  # [@DEFAULT_UNSET]
>  # [@REQUIRED]
> +# [@INCLUDES_EPREFIX] (the variable is a path that includes ${EPREFIX})
>  # @DESCRIPTION:
>  # 
>  # foo=""
> @@ -252,6 +255,10 @@ function handle_function() {
>   internal = 1
>   getline
>   }
> + if ($2 == "@INCLUDES_EPREFIX") {
> + includes_eprefix = 1
> + getline
> + }
>   if ($2 == "@DESCRIPTION:")
>   desc = eat_paragraph()
>  
> @@ -314,6 +321,8 @@ function _handle_variable() {
>   user_variable = 1
>   else if ($2 == "@OUTPUT_VARIABLE")
>   output_variable = 1
> + else if ($2 == "@INCLUDES_EPREFIX")
> + includes_eprefix = 1
>   else
>   opts = 0
>   }

That looks like a good idea.

Yours,
Benda


[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 check will therefore be adjusted
> to merely ensure that SYSROOT is / when ROOT is /.

It is very encouraging to see contributions from the ChromiumOS team to
Gentoo!

> 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 always ${SYSROOT}${EPREFIX}. We
> therefore cannot do it! If the crossdev prefix is blank then ROOT's
> must be blank too.

My question: is there a case when both SYSROOT and ESYSROOT are needed?
As far as I can see, SYSROOT is strictly build-time. Therefore setting
SYSROOT= would be enough for all.

Why did ESYSROOT exist in the first place?  Was it only for the sake of
symmetry, or did I miss something?

> It was originally envisaged (but not stated in PMS) that SYSROOT would
> only ever need to equal / or ROOT as a distinct SYSROOT would have no
> benefit.
...
> There were differing assumptions about how prefixes applied to the
> above. EPREFIX is traditionally something the user sets so some
> thought that it would be applied to SYSROOT, regardless of the
> latter's value. In order to honor the rule about there being no
> distinct SYSROOT, this would mean that if SYSROOT is / then EPREFIX
> would have to match BROOT.
...
> I also never intended to have the aforementioned limitation where
> EPREFIX must match BROOT when SYSROOT is /. These are both entirely
> artificial restrictions.

I agree. This is an artificial restrictions.

> What about the cross-prefix case? Here, SYSROOT matches both / and
> ROOT so which prefix do we choose? The bootstrap-prefix.sh script sets
> flags to build against the target prefix so EPREFIX is used in this
> case. This happens to fit the current definition of ESYSROOT anyway.

In this bootstrap case, SYSROOT=EPREFIX would do.  Again, no ESYSROOT is
needed.


In conclusion, IMHO, if SYSROOT can be overridden without restriction
("distinct" in your email), we could cover all the use cases.

Yours,
Benda



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 change.

Yours,
Benda


signature.asc
Description: PGP signature


[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 developed independently, regardless of
>> whether any development effort is supported by 3rd party.
> [...]
>> Personally I don't regard the GSoC selection and decision process
>> interesting to all the Gentoo devs.
>
> In my opinion Michał has got a very good point regarding potential PR
> consequences of us rejecting GSoC work. 

I agree with you.

> Of course it can be done, I've seen my share of student projects of
> various sort getting binned immediately after implementation - but
> more often than not it shows a lack of of foresight, at best, on
> behalf of institutions which requested manpower for such projects.

Agreed, too.  It is the mentor's duty to facilitate a win-win outcome to
our student, Gentoo and Google, by being more careful on visions and
planning.

> Yes, it is good for you to have eventually brought this to -dev - but
> IMHO it really is too late. In the future, I would STRONGLY advise
> having a general discussion before having even a single line of code
> written.

In retrospect, I was overconfident about my technical judgement.  I will
take your advice.  Thank you, Marek.

Yours,
Benda


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 safer way to remove ebuilds.

> This was actually done for the change that was reverted yesterday, but
> it seems like the CI results were ignored and the commit was pushed
> regardless.

Yesterday the original pull requests by Mo did not remove ebuilds.  It
was only when I started to adopt the PR that I saw

> RepoMan scours the neighborhood...
>   repo.eapi-deprecated  1
>virtual/cblas/cblas-1.0.ebuild: 5

after which I impulsively killed it.


I should take this lesson and be more careful removing ebuilds.

Yours,
Benda



[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
> GSoC.  However, both projects we have this year [1] involve major
> changes to ::gentoo that -- by policy -- require prior RFC.  In case
> of the BLAS/LAPACK project there was a RFC *after* the project was
> accepted, that was never fully answered.  In case of the MPI project,
> I'm not aware of any public RFC or announcement.

The proposal has been discussed in regular mailing lists.  

  
https://archives.gentoo.org/gentoo-science/message/4d0186acdce6df538a2740e0f1146ae6

At the proposal stage it was not sent to gentoo-dev, because I thought
only science project was relevant to BLAS/LAPACK.  Later we find it to
be affecting more ebuilds, thus the RFC was sent to gentoo-dev.

  
https://archives.gentoo.org/gentoo-dev/message/d917547f7a9e1226fca63632a1e02026

> I believe such decisions put all of us in a very bad position.  There is
> a major work going on, almost secretly.  In the end, we will either be
> forced to accept the result even if it doesn't meet our expectations, or
> reject it and turn GSoC into some kind of grotesque situation.

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 developed independently, regardless of
whether any development effort is supported by 3rd party.

> The former is of course unacceptable from my point of view.  It would
> mean that one or two developers are able to abuse paid programs such
> as GSoC to unilaterally push their preferences into Gentoo.  We would be
> forced to accept them unconditionally just because 'it's a done deal'.

See above.

> The latter means the students has wasted their summer doing work that's
> not going anywhere.  This is certainly demotivating and a bad PR for
> Gentoo.  I suppose it also reduces our chance of getting into GSoC
> again, if Google finds out that GSoC is spent on code going to trash.

That's why we are working together to find the best solution and reach a
consensus.

> So, again, why do single developers unilaterally decide on which
> projects third party money is spent, and never bother discussing whether
> those projects are really applicable beforehand?

I will leave this question to our GSoC manager.

Personally I don't regard the GSoC selection and decision process
interesting to all the Gentoo devs.  If you are interested in GSoC and
would like share your ideas to recruit student enthusiasts, you are more
than welcomed to join our team.

> [1]
> https://summerofcode.withgoogle.com/organizations/6416323580526592/

Cheers,
Benda


signature.asc
Description: PGP signature


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, I'm willing to accept this under a USE="lapack_targets_virtual"
> configuration, 

I hear you, and I was with the same opinion, too.

Nevertheless, if a runtime switch works, it is simpler than USE_EXPAND.

We already have a couple of them, PYTHON_TARGET, RUBY_TARGET, etc.  I
don't want to add more to this list unless absolutely necessary.

Alternatively, it could be exclusive USE flags instead of USE_EXPAND.
That's possible and we need to add a lot of USE flags, OpenBLAS, blis,
reference, altas, nvBLAS, etc.  I don't think it a clean solution.

> but wholesale editing of DT_NEEDED entries is definitely too scary and
> too invasive for most non-sci/hpc users of Gentoo.

Sorry if I confused you.  There is no hack of DT_NEEDED involved.

An application is compiled against the reference, then it is pointed by
LDPATH and ld.so.conf to a drop-in replacement library, and it profits.
That's not more than upgrading a dynamic library.

The scheme was shown to work with gcc runtime, libstdc++, and opengl, in
Gentoo.

> Again, for 99% of users, OpenBLAS will be the right trade-off between
> performance and customizability. Every recompilation of libreoffice or
> chromium will devour more CPU cycles than switching between USE-flag
> implementations.

I understand your point.  Let me elaborate:

1. OpenBLAS has quite a bit of hand-tuned assembly, it is not very
   portable.  Special care is need to manage the default BLAS on
   profiles, like ppc64, arm64, arm, riscv, etc.

2. All the Gentoo users care about optimization.  And there are
   non-science applications that call linear algebra routines.

3. Maintaining different BLAS frameworks in repo/gentoo.git and
   proj/sci.git wastes everybody's time, and causes endless confusion to
   users.  That offsets the time saved to make OpenBLAS the global
   default.

Therefore, from the users' point of view, I still think runtime
switching makes more sense.

Yours,
Benda



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 difference
>> in SONAME hampered the gentoo integration of well-optimized ones.
>
> If SONAMEs are different, then they are not compatible by definition.

This blas/lapack SONAME difference is a special case.  They are parially
compatible in the sense that every alternative implementation of blas is
a superset of the reference one.

Therefore linking to the reference at build time will make sure the
compatibility with the alternative implementations, even with different
SONAME.

>> [...]
>> 
>> Similar to Debian's update-alternatives mechanism, Gentoo's eselect
>> is good at dealing with drop-in replacements as well. My preliminary
>> investigation suggests that eselect is enough for enabling BLAS/LAPACK
>> runtime switching. Hence, the proposed solution is eselect-based:
>> 
>>   * Every BLAS/LAPACK implementation should provide generic library
>> and eselect candidate libraries at the same time. Taking netlib,
>> BLIS and OpenBLAS as examples:
>> 
>> reference:
>> 
>>   usr/lib64/blas/reference/libblas.so.3 (SONAME=libblas.so.3)
>> -- default BLAS provider
>> -- candidate of the eselect "blas" unit
>> -- will be symlinked to usr/lib64/libblas.so.3 by eselect
>
> /usr/lib64 is not supposed to be modified by eselect, it's package
> manager area.  Yes, I know a lot of modules still do that but that's no
> reason to make things worse when people are putting significant effort
> to actually improve things.

Sorry, I didn't see your reply before mine.

We are going to use the LDPATH and ld.so.conf mechanism suggested by
you.

>>   usr/lib64/lapack/reference/liblapack.so.3 (SONAME=liblapack.so.3)
>> -- default LAPACK provider
>> -- candidate of the eselect "lapack" unit
>> -- will be symlinked to usr/lib64/liblapack.so.3 by eselect
>> 
>> blis (doesn't provide LAPACK):
>>   
>>   usr/lib64/libblis.so.2  (SONAME=libblis.so.2)
>> -- general purpose
>> 
>>   usr/lib64/blas/blis/libblas.so.3 (SONAME=libblas.so.3)
>> -- candidate of the eselect "blas" unit
>> -- will be symlinked to usr/lib64/libblas.so.3 by eselect
>> -- compiled from the same set of object files as libblis.so.2
>> 
>> openblas:
>>   
>>   usr/lib64/libopenblas.so.0 (SONAME=libopenblas.so.0)
>> -- general purpose
>> 
>>   usr/lib64/blas/openblas/libblas.so.3 (SONAME=libblas.so.3)
>> -- candidate of the eselect "blas" unit
>> -- will be symlinked to usr/lib64/libblas.so.3 by eselect
>> -- compiled from the same set of object files as
>> libopenblas.so.0
>> 
>>   usr/lib64/lapack/openblas/liblapack.so.3 (SONAME=liblapack.so.3)
>> -- candidate of the eselect "lapack" unit
>> -- will be symlinked to usr/lib64/liblapack.so.3 by eselect
>> -- compiled from the same set of object files as
>> libopenblas.so.0
>> 
>> This solution is similar to Debian's[3]. This solution achieves our
>> goal,
>> and it requires us to patch upstream build systems (same to Debian).
>> Preliminary demonstration for this solution is available, see below.
>
> So basically the three walls of text say in round-about way that you're
> going to introduce custom hacks to recompile libraries with different
> SONAME.  Ok.

>> Is this solution reliable?
>> --
>> 
>> * A similar solution has been used by Debian for many years.
>> * Many projects call BLAS/LAPACK libraries through FFI, including Julia.
>>   (See Julia's standard library: LinearAlgebra)
>> 
>> Proposed Changes
>> 
>> 
>> 1. Deprecate sci-libs/{blas,cblas,lapack,lapacke}-reference from gentoo
>>main repo. They use exactly the same source tarball. It's not quite
>>helpful to package these components in a fine-grained manner. A
>> single
>>sci-libs/lapack package is enough.
>
> Where's the gain in that?

>> 2. Merge the "cblas" eselect unit into "blas" unit. It is potentially
>>harmful when "blas" and "cblas" point to different implementations.
>>That means "app-eselect/eselect-cblas" should be deprecated.
>> 
>> 3. Update virtual/{blas,cblas,lapack,lapacke}. BLAS/LAPACK providers
>>will be registered in their dependency information.
>> 
>> Note, ebuilds for BLAS/LAPACK reverse dependencies are expected to work
>> with these changes correctly without change. For example, my local
>> numpy-1.16.1 compilation was successful without change.
>> 
>> Preliminary Demonstration
>> -
>> 
>> The preliminary implementation is available in my personal overlay[4].
>> A simple sanity test script `check-cpp.sh` is provided to illustrate
>> the effectiveness of the proposed 

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, that was the conclusion in 2017.  

But now there is something to be renewed, see below.

> Optionally, we can leave a "virtual" USE flag, where users can switch
> implementation at runtime, but this will not be a supported
> configuration.

[...]

> While I understand that runtime-switching sounds like a great feature,
> it has proven too difficult to get right and too hard to enforce
> invariants on correct symlinks.

I thought so, too. Back in 2017, I did an investigate of Debian runtime
switching, and concluded the patches were too heavy for us. That was the
main reason we did not consider the Debian runtime switching way.[0, 1]

However, I have made a deeper study this year, and concluded it is quite
doable in a simple way in Gentoo.


Historically, in alternative{,-2}.eclass of the science overlay,
"alternative" is a name from Debian[2]. We have made it too complex over
the years, and now there is a good chance to make it simple again.

> People that want this can go the virtual+eselect approach in the
> overlay,

Which is brittle and shaky as we agree.

> but 99% of Gentoo users will be happy with just linking against
> OpenBLAS/reference-lapack and not having to fix weird stale symlinks
> that eselect-alternatives somehow lost track of.

With the simplified approach Mo is after, there will no longer be weird
stale symlinks issues.  The solution has been successfully proved by the
update-alternative mechanism in Debian.  Actually, by adopting mgorny's
LDPATH way of handing gcc runtime, we don't need symlinks at all![3]

For more details, please refer to
https://people.debian.org/~lumin/gsoc19-gentoo.pdf

> See also:
> https://bugs.gentoo.org/632624
> https://bugs.gentoo.org/348843#c30

Thanks. That reminded me of all the discussions we all along.

Yours,
Benda

0. https://github.com/gentoo/sci/issues/805#issuecomment-345690034
1. https://github.com/gentoo/sci/issues/805#issuecomment-345701064
2. https://github.com/gentoo/sci/issues/805#issuecomment-332887691
3. https://bugs.gentoo.org/632618



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 project has been on my list for ages and you've made it
real.  Your efforts on EAPI-7 and cross python modules are much
appreciated.

Yours,
Benda



[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 situations?). Fixing packages without
> touching eclasses doesn't require gentoo-dev review.
>
> Also, netsurf doesn't have any prefix keyword. Some of the lower-level
> libs have ~m68k-mint, but it isn't clear why because the only
> non-netsurf revdep to those libs is net-libs/libwebsockets and it isn't
> keyworded for prefix either.
>
> Please, open a ticket on the appropriate package with a description
> of an actual breakage and I'll be deligthed to address it.

Well, all in all, thank you for stepping up to take care of
netsurf-buildsystem.  You're good.

Yours,
Benda


signature.asc
Description: PGP signature


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
eclass.  The new ebuild breaks Prefix.  For example,

  NSSHARED=/usr/share/netsurf-buildsystem

This is a serious regression for Prefix and caught a lot of users
without a warning.  Could you please discuss on this kind of changes in
the mailing list beforehand?

Yours,
Benda


signature.asc
Description: PGP signature


[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 first time it
> killed the whole system.

While I agree with you that mercurial is less well-maintained than git,
this seems to me that the sync framework is more buggy than mercurial.

Benda


signature.asc
Description: PGP signature


[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
An rpath profile uses host glibc and uses explicit keywords
"${ARCH}-linux".  Therefore arm-linux represents rpath flavor of arm
Prefix.

In the profiles/, however, we use "arm-linux" to represent Prefix in
arch.list and profiles.desc.  And that bears no relation with keywords
in the ebuilds.


How did "arm-linux" appear?  Around 2013, both the ARM Arch Team and the
Prefix Team were interested in supporting Prefix on ARM.  In the Prefix
Team, a debate of implicit vs explicit keywording was on-going.  At the
same time, the ARM Arch Team went ahead to plant arm-linux into the
tree.

What is the status of "arm-linux" keywords?  They are unmaintained and
has not been touched for 5+ years.  At present, the Prefix Project is
phasing out Linux rpath profiles and using libc profiles as default.
There has been no commit in the gentoo.git history regarding "arm-linux"
keyword. The gentoo-x86 CVS history shows the commit author was mainly
Zac (zmedico).

What is recommended?  Just use the "arm" keyword, it has been proven to
work well as an implicit ARM Prefix keyword by the Android Project[2].


"arm-linux" is considered deprecated, unmaintained and easily replaced
by "arm".  I propose removing it from gentoo.git completely.

Yours,
Benda


1. https://bugs.gentoo.org/664598
2. https://wiki.gentoo.org/wiki/Android/Devices



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 coming from in general-- that we've
> already achieved a good minimal balance in enabling udev only where
> it's really needed, and enabling it in linux make.defaults will make
> it difficult to get back to that state.
>
> So I will just continue to ask for IUSE=+udev where I believe it's
> very important for sane functionality of a particular package.  In
> other words, I'm no longer pushing for the make.defaults change.

Glad we are back to the common ground again.  Have fun hacking.

Yours,
Benda



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 implies a stable default, the one that does not
change for a weak reason.

The reasons are weak for switching udev on, and weak for switching
glibc, openrc, bash etc. off.

If it ain't broke don't fix it.  Changes without consensus cause more
trouble than good.

Yours,
Benda



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 project.

Yes, if the Linux profile enables it, we will have to disable it
explicitly in the Linux Prefix profiles.

Cheers,
Benda


signature.asc
Description: PGP signature


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 useful functionality that most linux users will
> want. I'm a bit surprised that we still don't have it in all linux
> profiles, but I think we've worked around this in the past by adding
> IUSE=+udev to quite a few of those packages (33 packages, 116 ebuilds,
> by my count).
>
> This missing flag came to my attention again on bug 661584 where lvm2
> has IUSE=+udev but cryptsetup has only IUSE=udev, so non-desktop users
> have a bit of a mismatch between the 2 and get ugly errors on
> cryptsetup.

I expect this to be fixed on the package-by-package basis.

> Since this flag only affects linux, I think it makes more sense to set
> it in linux profiles than to use IUSE defaults.
>
> Any objections to this idea?

To represent the Gentoo Prefix users, we would like to have USE=udev
turned off or even hard masked on linux-prefix profiles.

Yours,
Benda



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 outdated and will be removed
> soon. It was already just a mirror of the new link for some time. The
> new link is:
>
> https://gentooqa.levelnine.at

The statistics looks very nice!  I have bookmarked it.

Thank you for your work.

Yours,
Benda


signature.asc
Description: PGP signature


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:

  http://www.catb.org/esr/faqs/smart-questions.html#classic

  http://www.catb.org/esr/faqs/smart-questions.html#urgent

Benda



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 not whitelisting,
> but it seems silly to blacklist.

Okay, I see your argument.


Just a random bikeshedding.  We might be able to require GPG signed
email to make a post.  Then we can blacklist the GPG identity?

To think of it further, the web of trust is basically a whitelist.  But
it has the flexibility to chain the trust from a Gentoo dev by several
'hops'.

Benda



[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 code that belongs to news items after updating port
> tree.Explain its implementation also.
>
> Thank You

If you are aiming for summer of code, move your question to
gentoo-soc@l.g.o.  If you are interested in the internals of portage,
read the code first and ask on gentoo-portage@l.g.o.

I don't think anyone will explain its implementation to you unless you
do the study and show your competence first.  Your behavior of
re-posting the same message is considered rude.

Yours,
Benda



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 not necessary.

I agree with William.  Dealing with individuals makes more sense.

It boils down to an attitude of assuming outsiders are good (blacklist
to ML) or bad (whitelist to ML) by default.

Benda


signature.asc
Description: PGP signature


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 scared off any serious attempts at packaging.
>
> Seeing as there has been interest in nodejs packages, and in the end
> we could be talking 400-600+ packages, would it be possible to create
> dev-libs/nodejs category? I would be happy to write and proxy-maintain
> ebuilds for a large number of them to get things in motion. I've
> already opened pull request #7427 [1] for chalk and its
> dependencies. I'm aiming to build up to all the dependencies needed
> for Visual Studio Code OSS.
>
> [1]:https://github.com/gentoo/gentoo/pull/7427

Your effort will be much appreciated.  I support your plan.

Should the category be dev-js intead?  To me, node.js is but an
implementation of javascript runtime.


BTW, for the 400-500 packages, are you going to create them with a
generator script?

Cheers,
Benda



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 flags settings for certain packages.
>
> But over the time this list became small and smaller and eventually
> this month I kicked off the last few lines (famous last words?).
>
> Said that Gentoo has IMO a lot of success stories to tell too (beside
> the usual grumblings and annoyances) - and the quality of the Gentoo
> tree is IMO an example of that.

Thanks a ton for the tinkerbox and for the early bug reports!

This is the crucial way to keep our tree healthy.

Cheers,
Benda


signature.asc
Description: PGP signature


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.
>
> For example, many languages such as Python (pip), Node (npm), Ruby
> (gems), TeXLive (tlmgr), Haskell (cabal), Rust (cargo) have ways of
> redistributing up-to-date dependencies and ensuring that they build
> properly in most environments. Portage, it seems, does not take
> advantage of this at all. If I want to install the package 'foo',
> which has 'bar' as a dependency (which has been installed through
> cabal, for instance). Why should portage download some outdated second
> copy of the sources for 'bar', rebuild it, and scatter it around the
> file system where it cannot be used by other programs installed by
> cabal?

There have been quite a lot of effort before.  What I know are:

* R_Overlay

R_Overlay uses roverlay[1] to generate ebuilds from CRAN and BIOC.  It
works for 90% of the packages, and has a dozen of users.

The biggest burden of maintenance is parsing random strings upstream
would put in the dependency fields (e.g. [6]).


* Maven Overlay

It is based on java-ebuilder[2] to generate ebuilds from Java Maven
repository.  The proof of concept overlay works well for Apache
spark[3].

A bit of scripting resolved the incompatibility of version schemes
mentioned by kentnl[5].

I am proposing a GSOC idea to mentor a student on it,

  
https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2018/Ideas/Maven_Java_overlay

* g-sorcery

A general purpose ebuild generator in Gentoo (app-portage/g-sorcery)[4],
I have been using it for pip (app-portage/gs-pypi) and elpa
(app-portage/gs-elpa).  It works but a bit out-of-date.  Help welcome.


>From my experiences with the ebuild generators, they can be made very
reliable and painless. 

By far IMHO the R Overlay is the most successful.  The overlay is
generated on a server exposed into layman list.  The generation process
needs to be maintained and can have bugs when the upstream evolves.  It
can be a pain for an average user to debug.

Therefore, Gentoo semi-offical automatic overlays from language-specific
repositories provides a promising potential solution.

Yours,
Benda

1. https://github.com/dywisor, developed by dywisor as a GSOC project
   with calchan.

2. https://github.com/gentoo/java-ebuilder, lead by fordfrog of the Java
   Project.

3. https://github.com/heroxbd/maven-overlay

4. developed by jauhien as a GSOC project.

5. 
https://archives.gentoo.org/gentoo-dev/message/487f5eb7b2d1ba00ae607b3f88bbb8c9

6. 
https://github.com/dywisor/roverlay/blob/master/config/simple-deprules.d/dev-libs



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 rather ignore the
timestamps when comparing two binaries.

Benda



[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.  You'll note that you can't actually see
> anything that you couldn't see before.  If you run ps -ea you'll see
> that you're the only process running on the system.  Devices like
> /dev/sda aren't actually accessible.  A lot of container managers
> would mount a new /dev and just hide most of that stuff.  You can
> probably imagine how something like this could be useful for isolating
> processes.  

Just a side node, this seems to be the ultimate sandbox we (Gentoo and
portage) are after.  With this, we might even be able to have portage
full functional: a build is completely determined and only determined by
the dependencies and USE flags.



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 management. For example...

I just want to point out one very nice article by Michael thoroughly
discussing there issues:

  
http://michael.orlitzky.com/articles/motherfuckers_need_package_management.xhtml


This title itself is amusing enough

  Motherfuckers need package management


Benda








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 filesystem with no way to identify these
> or clean them up.  They're usually written by the same sorts of people
> who tell you to pipe curl into sudo bash...

One observation.  There are a lot of people on this planet who will
format their disk and reinstall their whatever operating systems upon
getting fscked by random programs downloading random stuff and dropping
orphan files all over their filesystem.  So far the volume of this group
of people is growing fast.

That give an illusion of tolerance from the users, enouraging this evil
to go deeper.

Luckily in Gentoo, we are with competent friends who are taking care of
their own systems.

Cheers,
Benda




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 keywords, prefix-standalone uses usual
keywords, not prefix keywords.

  
https://wiki.gentoo.org/wiki/Project:Prefix/Technical_Documentation#Search_pathes

> If you really must unmask them in a specific prefix profile, you must
> provide big fat warnings about the resulting security risks.  (I dont
> know how things went in prehistoric times, but recently there have
> been a LOT of glibc-related CVEs. Many fixes can be backported, but
> definitely not all of them.)

Yes, I think that's the way to go to keep users reminded of security
risks involved.

> * No toolchain-glibc.eclass or eblits or similar abominations. Standard QA 
> rules apply.

Agreed!  Old glibc becomes a burden for toolchain-glibc.eclass
maintenance.  We'd better make them standalone.

> * Try to stick to a minimum of required features (and a minimum of required 
> versions).
> We want to strongly avoid adding conditionals to other packages. [#]

Sure, the feature set will be kept bare minimal.  For example, handened
patches will be removed.

> * Please use our gentoo glibc repo to keep track of branches and patchsets.
> Happy to show you the details sometime soon.

Thanks Andreas.  Much appreciated.

> [#] If not for such "old version" considerations, we could soon move the 
> libtirpc headers to the place where the glibc headers used to live. That 
> could 
> save us a ...load of patching and bugfixing. By keeping flexibility and 
> compatibility, that is unfortunately not possible.

That's where I see providing glibc-2.16 and 2.19 in special profiles
might shed light on this delimma.  We keep versions of glibc to make
sure some old systems do not break.  But those systems are not clearly
defined.  We don't have a guideline for when and how to remove them.
(We used to keep them almost indefinitely before the reformation of
toolchain project.)

By explicitly spelling out the range of kernels a specific glibc
supports, and only keeping the minimal set of old versions, the
boundaries are defined.

Cheers,
Benda


signature.asc
Description: PGP signature


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 generate some noise for toolchain@g.o.  But I
>> anticipate people on the team are interested in receiving those emails.
>
> That's not a solution. That's cheap a cheap excuse that works for one
> package, for today. It does not solve the generic case,

What I ask is a special treatment of glibc.  I do not intend to explore
a generic solution in this thread.  And don't get me wrong, I support
tree cleaning by all means.

Glibc is special, llvm is the only other (not so similar) example.  No
more package will be special like this.  This will not set a bad example
or bad excuses for keeping outdated ebuilds.  I don't see your argument
of generic case.

> it does not mean that other members of toolchain or any other team
> will not end up having to remember extra rules like 'do not remove
> this ebuild because X wants it'.

Is that a problem?  When at least 1 person is eager to maintain an
package, the package could be kept.  Consider that person as the de
facto upstream.

Consider glibc-2.16 as a sys-libs/glibc-revived package that is too
closely connected to sys-libs/glibc be treated as a 2nd package.  Then
the package argument carries to a special version of ebuild.

Cheers,
Benda


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
> uses, and for which RH still provides support (until 2020 for 2.5,
> 2024 for 2.12)...
> https://sourceware.org/glibc/wiki/Release#Distribution_Branch_Mapping

> That however would require that the RHEL patchsets are public
> somehwere. Which I doubt... after all there's an "E" in RHEL...

> [...]

> ... except that my personal motivation has dropped somewhat when
> noticing that the CentOS package applies 552 (!) patches on top of
> 2.17.

Carrying Redhat patches are not only technical unfeasible, but also out
of our best interest.  The reasons are the following.

glibc-2.5 does not support fortify, thus breaking gentoo version of gcc
since verison 4.3 (Bug 289757).  The original purpose of
prefix-standalone was to introduce newer glibc from gentoo to solve this
issue.  So shipping glibc-2.5 requires maintaining seperate versions of
gcc.

glibc has some tolerance for kernel.  2012 glibc-2.16 supports 2004
linux-2.6.8.  It buys us 8 years!  That's the basis for the magic of
prefix-standalone.  gcc in turn has some tolerance for glibc.  So far
glibc-2.16 is still supported by the newest gcc but glibc-2.5 is
definitely out of the game.

I hear your instinct for RHEL versions for security consideration.  But
in this use case, the kernels are usually outdated for many years and
prone to multiple privilege escalation CVE's.  If the administrators of
these systems cared about security, these antiques wouldn't have existed
in the first place.

Therefore, using edge versions of glibc-2.16 (newest glibc to support
linux 2.6+) and 2.19 (newest glibc to support linux 2.6.16+) makes more
sense.

Yours,
Benda


signature.asc
Description: PGP signature


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 LLVM example, it is prefix-rpath, which hosts its own overlay at
>> repo/proj/prefix.git.  Besides LLVM there are other hacks at present in
>> the overlay.  But we still keep the ultimate goal of merging prefix.git
>> into gentoo.git.
>
> I am also keeping old versions of LLVM for Prefix team. That's why I'd
> really prefer to get rid of them and have them in some common overlay
> that all Prefix users can use.

Yes that's true. The case of LLVM for prefix-rpath is similar as glibc
for prefix-standalone.

For the argument of overlay refer to the message below vvv

>> What we are discussing in this thread, however, is prefix-standalone, it
>> uses the official gentoo repository without any overlay.  It works
>> perfectly for kernel-2.6.26+ and linux-3.2+.  So, creating an overlay of
>> 2 ebuilds for prefix-standalone is an overkill.
>
> Maybe it is. But isn't making maintenance of Gentoo packages more
> complexity for Prefix an overkill? We are effectively switching
> from trivial model of 'assign bug with X to maintainer' to checking
> which maintainer applies to which version of X.

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 generate some noise for toolchain@g.o.  But I
anticipate people on the team are interested in receiving those emails.

Cheers,
Benda


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.  Synonymically, 1 glibc ebuild
will allow the rest of the Gentoo tree compile and run on 10+ years old
platforms.

The users trapped with antique OS will be able to use tools from Gentoo,
and Gentoo will expand its horizon for new use cases.

Detailed replies inline, mostly repeating of the above point for special
cases.

William Hubbs  writes:

> I am with mgorny on this, this sort of specialized support does not
> belong in the main tree.
>
> The kernel versions you are talking about aren't even supported by the
> upstream kernel folks any more -- the oldest lts version is 3.2.99.

I am with you.  I don't care about outdated kernels.  Therefore I am
interested in a compatible layer that screens out the kernel.  So far, 1
glibc does the job.

Alec Warner  writes:

> So I actually originally thought this as well and settled on some
> logic that is:
>
> The problem we are trying to solve is supporting very old
> distros. This has two impacts on the tree:

> a) Very old versions of some packages stay in the tree because they
> are needed to support these old platforms.

s/some packages/1 glibc ebuild/

The concerned package is only 1 version of glibc per a group of kernels,
no more.  It is well-contained, not a can of worms.

> b) Very old versions of some packages will need to drop keywords for
> 'rolling' platforms. E.g. I'd expect glibc-really-old to be keyworded
> only for 'prefix' but not for 'x86' or 'amd64'.

To clarify, prefix-standalone uses implicit keyword scheme, the same
usual keywords as 'amd64'.  We could mask the old versions as the status
quo.

> This is because the latter two are not well tested[1]
>
> A and B are both mostly about control and maintenance of the tree
> itself (these do not necessarily reflect the quality or stability of
> prefix as a platform.)
>
> The separate problem is:

> Given some prefix users are running prefix on these old platforms, how
> do we detect when support for them breaks (as it did for py3, and will
> again in the future when something else critical breaks.) 

We can require each platform (or profile) to have at least 1 dev as an
active user, for example:

  https://wiki.gentoo.org/wiki/Project:Prefix#Platform_matrix

Recently, I have found an ultimate solution to the python3 puzzle.
Usually, glibc exposes all the symbols it supports.  Whether the kernel
supports the symbols are determined at runtime.  But, if the glibc is
patched to be faithful to the kernels it is running on, python3 happily
compiles and runs.  And yes, we know exactly what kernels are expected,
e.g. glibc-2.16 for linux-2.6 ~ 2.6.15.  Therefore we have a define goal
to patch the glibc.

By this strategy, even RHEL4 runs python-3.6 well.

> I'm curious to hear more about this process, but I think its
> orthogonal to in-tree or in-overlay support; other than the overlay
> gives you more control over when to release / withdraw various package
> versions (more control than just keywords do in the main tree.)  Note
> that Gentoo itself purports to offer only 1 year of support for the
> main tree; so just based on that axiom alone I think trying to support
> 10+ year old platforms goes against what the main-tree is targeting.

Again, a glibc ebuild isolates the antique kernel and all the dirty work
of supporting 10+ year old platform is absorbed in 1 ebuild.  Therefore
the 1-year-of-support model of Gentoo tree is not violated and
untouched.

Hope that address the concerns of potential degradation of our main tree
quality.

Cheers,
Benda


signature.asc
Description: PGP signature


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 subset
of GNU/Linux; the other is prefix-standalone, targeting GNU/Linux and
Android/Linux.[1]

For LLVM example, it is prefix-rpath, which hosts its own overlay at
repo/proj/prefix.git.  Besides LLVM there are other hacks at present in
the overlay.  But we still keep the ultimate goal of merging prefix.git
into gentoo.git.

What we are discussing in this thread, however, is prefix-standalone, it
uses the official gentoo repository without any overlay.  It works
perfectly for kernel-2.6.26+ and linux-3.2+.  So, creating an overlay of
2 ebuilds for prefix-standalone is an overkill.

Yours,
Benda

1. https://wiki.gentoo.org/wiki/Project:Prefix


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
>> infrastructure of the Toolchain Project[5];
>> 
>>   - (optional) add an exception to the toolchain support policy[6].
>
> How about moving them to an overlay?

I have reflected on this option and concluded it is an overkill to
create an overlay for only 1 package.

Yours,
Benda


[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 set out to rescue users trapped in
these abandoned wastelands of antiques.  After years of work, we have
achieved that goal, except one minor thing: glibc periodically drop
support for old linux kernels, the lastest glibc supporting linux 2.6.8
is 2.16 and for linux-2.6.18 it is glibc-2.19.

With the recent reunion of the Toolchain Project, old glibc versions are
masked and removed, accelerating the adoption of new versions.  This
opens a new oppotunity for the Prefix: people stops caring about
unsupported glibc versions, the Prefix Project can take them over
without worrying about breaking other peoples' machines.

Now, profiles/default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.16+
unmasks https://bugs.python.org/issue28092
2. https://bugs.python.org/issue31255
3. https://bugs.python.org/issue29157
4. 
https://archives.gentoo.org/gentoo-project/message/7eb61502d827476a9326b0f180dbd2fa
5. https://wiki.gentoo.org/wiki/Project:Toolchain/Patchsets_with_Git
6. https://wiki.gentoo.org/wiki/Project:Toolchain/Support_policies



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 ownership of /lib* and /usr/lib* as well.

This is an abrupt change that will affect many users.  I suggest a
lengthy explanation (blog post, wiki page or important emails) to be
attached as a reference in this news item.  

So a user will be able to study the rationales behind this change before
unmasking baselayout-2.5 on their machines.

Yours,
Benda


signature.asc
Description: PGP signature


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.
>
> On Thu, Feb 08, 2018 at 10:17:59PM +, M. J. Everitt wrote:
>> 
>> Pardon my ignorance, but does that mean you are essentially relying on
>> file system features/permissions and security settings to enforce
>> correct use of system tools?! Or is this just to make sudo/etc commands
>> 'more convenient' ?!
>
> The basic problem is that what goes in *bin vs *sbin is quite arbitrary
> and the best way to fix it is to make all of the *bin and *sbin
> directories accessible to all users.
>
> You can't rely on a path to separate system-only programs from
> programs that users might want to run, and some programs can be run by
> users to look around but not change things.
>
> Here is one non-gentoo source discussing this.
>
> http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
>
> Even if we don't adopt the usr merge in Gentoo Linux as default, removing 
> *sbin
> from the path doesn't make sense.

If there references are useful for users to understand why this decision
and potential breakage is made, it might be a good idea to append the
links to the news item.

Yours,
Benda


signature.asc
Description: PGP signature


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.)
> *>
>*=>
>   *==>
>  *===>
>
> vs.
>
> (Usually seen.)
> *==*
>*==*
>   *==*
>  *===>
>
> vs.
>
> (What it would actually mean for prefix.)
> *==*->
>*==*-->
>   *==*--->
>  *===>
>

Nice assci art! Indeed the 3rd case is what I want to express.  It is a
big challenge though to express it within 20 characters in the profile
name.  So I chose the first one as approximation.

>>> This setup would prevent having to verify that old code works on new
>>> systems, which is implied to be supported.by the + naming (again, not
>>> sure if it matters).
>>
>> It is always supported to run an old glibc version on a new kernel, the
>> linux kernel is ABI-backwords compatible.  There is no need to verify
>> that.  Besides, by always using the most recent
>> sys-kernel/linux-headers, we are guaranteed with the newest kernel API.
>>
>
> It might be for the foreseeable future, but that might change. The
> comment was more about the features exposed to glibc and the programs
> installed via portage. It seems to me as the kernel and userland
> progress, The older profile would require constant adjustment. Perhaps
> I am not explaining it well, my apologies.

That is the norm for maintaining profiles.  We are actually doing
constant adjustment to profiles until they are deprecated and removed.
So don't worry.  We have enough time to react if that changes.

Yours,
Benda



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 developped Prefix on FreeBSD 8:

  https://wiki.gentoo.org/wiki/Project:Prefix

But now the port is outdated and removed in Jan 2017:

  
https://archives.gentoo.org/gentoo-alt/message/cf3af6ba4d2c56ea6c2451435b33eddf


You are more than welcomed to revive Prefix on FreeBSD.

Cheers,
Benda



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 recent kernel supported by the
> profile. So remove the plus and (I think) shift all of the names
> "forward."

> So 2.6.16 becomes 2.6.32, and 2.6.32 becomes the next profile's name.
>
> This seems more natural but does change the semantics of the
> name. Would that be a problem?

Let's call this 'breakage-indicating scheme'.  I have considered it, but
finally I chose the original proposal:

Consider one running kernel 3.8 with the newest profile, called
'prefix/kernel-3.2+' in the original proposal and 'prefix' in the
breakage-indicating scheme.  When glibc decides to break  Is it expected people would want to use the profiles with
> compatibility features on newer kernels?

One use case is that: I want to bootstrap on my new and powerful server
a 'prefix/kernel-2.6.16+' on kernel 4.9, and then transfer the resulting
Prefix to an aging RHEL 5.  Bootstrapping a 'prefix/kernel-2.6.32-older'
on kernel 4.9 feels awkward.

But it is not about use cases, it is about logical consistancy: if we
are not forbidden to run an old glibc on a new kernel, we should not
indicate so in profile names.

> This setup would prevent having to verify that old code works on new
> systems, which is implied to be supported.by the + naming (again, not
> sure if it matters).

It is always supported to run an old glibc version on a new kernel, the
linux kernel is ABI-backwords compatible.  There is no need to verify
that.  Besides, by always using the most recent
sys-kernel/linux-headers, we are guaranteed with the newest kernel API.

Yours,
Benda



[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 "Reply-To:" to the
author instead of the list?

Benda


signature.asc
Description: PGP signature


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 others

2.6.16+ means that it can be used in any cases when the kernel is newer
than 2.6.16.  For example, you can use it on linux-4.14, just with
unnecessary backward compatibility code.

Besides, with the newest profile, kernel-3.2+, the ending kernel version
is not known.  We will have to rename it when glibc jumps if the profile
is named with a version range.


Hope this addresses your concern.

Cheers,
Benda


signature.asc
Description: PGP signature


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 standard I am missing for profile names?

From PMS, there is no words on profile naming.  But I think adopting
naming of category [A-Za-z0-9+_.-] will not be too wrong:

  https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-170003.1.1

> Could there be a wiki explaining a prefix profile versioning that
> correlates to the glibc and kernel versions? Or is the intent to keep
> it simple and easily identifiable from within the PM?

A wiki page would be a good idea for detailed explanations.

> Not a big deal, but just my thoughts. Thanks for your work on prefix
> and I am sure many will benefit from the new profiles :)

Thanks for inputs!

Yours,
Benda


signature.asc
Description: PGP signature


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+
  default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.16+

Yours,
Benda


signature.asc
Description: PGP signature


[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) | <2.20 |
  | beyond-kernel-2.6.32 | [2.6.32, 3.2)| <2.24 |
  | beyond-kernel-3.2| [3.2, latest)| latest|

Attached is the patch.  Thoughts and comments?

Yours,
Benda
---
 .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi   | 1 +
 .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent | 2 ++
 .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi   | 1 +
 .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent | 2 ++
 .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi  | 1 +
 .../linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/parent| 2 ++
 profiles/default/linux/amd64/17.0/no-multilib/prefix/parent | 1 +
 profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/eapi| 1 +
 profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/parent  | 2 ++
 profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/eapi| 1 +
 profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/parent  | 2 ++
 profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/eapi   | 1 +
 profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/parent | 2 ++
 profiles/default/linux/x86/17.0/prefix/parent   | 1 +
 profiles/profiles.desc  | 6 ++
 15 files changed, 26 insertions(+)
 create mode 100644 
profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi
 create mode 100644 
profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent
 create mode 100644 
profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi
 create mode 100644 
profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent
 create mode 100644 
profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi
 create mode 100644 
profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/parent
 create mode 100644 profiles/default/linux/amd64/17.0/no-multilib/prefix/parent
 create mode 100644 
profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/eapi
 create mode 100644 
profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.16/parent
 create mode 100644 
profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/eapi
 create mode 100644 
profiles/default/linux/x86/17.0/prefix/beyond-kernel-2.6.32/parent
 create mode 100644 
profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/eapi
 create mode 100644 
profiles/default/linux/x86/17.0/prefix/beyond-kernel-3.2/parent
 create mode 100644 profiles/default/linux/x86/17.0/prefix/parent

diff --git 
a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi
 
b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi
new file mode 100644
index ..7ed6ff82de6b
--- /dev/null
+++ 
b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/eapi
@@ -0,0 +1 @@
+5
diff --git 
a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent
 
b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent
new file mode 100644
index ..6a349d3df196
--- /dev/null
+++ 
b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.16/parent
@@ -0,0 +1,2 @@
+..
+../../../../../../../features/prefix/standalone/beyond-kernel-2.6.16
diff --git 
a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi
 
b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi
new file mode 100644
index ..7ed6ff82de6b
--- /dev/null
+++ 
b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/eapi
@@ -0,0 +1 @@
+5
diff --git 
a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent
 
b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent
new file mode 100644
index ..f14f9dcf77ee
--- /dev/null
+++ 
b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-2.6.32/parent
@@ -0,0 +1,2 @@
+..
+../../../../../../../features/prefix/standalone/beyond-kernel-2.6.32
diff --git 
a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi 
b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi
new file mode 100644
index ..7ed6ff82de6b
--- /dev/null
+++ 
b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/eapi
@@ -0,0 +1 @@
+5
diff --git 
a/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/parent 
b/profiles/default/linux/amd64/17.0/no-multilib/prefix/beyond-kernel-3.2/parent
new file mode 100644

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:
>
> * https://github.com/Doeme/sci/blob/blas_lapack_eclass/eclass/blas.eclass
> * https://github.com/Doeme/sci/blob/blas_lapack_eclass/eclass/lapack.eclass
>
> [...]

The Science Team is very interested in this approach as it solves a
fundamental problem of BLAS[1] selection in Gentoo.  After the review,
we plan to land the 2 eclass-es into Gentoo main repository and start
ebuilds migration.

Your comments on the implementation are crucial to realize that.

Thanks!
Benda

1. Basic Linear Algebra Subprograms



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 require root to
execute.

So no worries, your workflow will not be affected.

Yours,
Benda



[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 Prefix users, who won't be surprised that
they cannot create new groups or users.  Therefore I think einfo is more
appropriate.


Furthermore, we do have Prefix that runs as root, mostly usable on NAS
or smartphones, when we do ultimately like portage to manage groups and
users.

Benda



[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 Prefix users, who won't be surprised that
they cannot create new groups or users.  Therefore I think einfo is more
appropriate.


Furthermore, we do have Prefix that runs as a root, mostly usable on NAS
or smartphones, when we do ultimately like portage to manage groups and
users.

Benda



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 the internals of Gentoo
Prefix.  Thank you for emphasizing this, you are acknowledged.

Benda



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 understood by a general user.



[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 bootstrap-rap scripts are more or less
> unmaintainable disasters.
> [...]
> and the bootstrap scripts are poorly explained with no extant
> documentation and a workflow that does not clearly fit into Gentoo (or
> more properly Portage) development at large.

As one of the maintainers of the bootstrap-prefix (and bootstrap-rap), I
acknowledge that the script is a result of accumulated contributions
from multiple people, with rounds of refactorizations in the past
several years. But it is well understood and maintainable.

I would like to remind you that, the script is a reflection of the
instrinsic complexity to compile a workable Gentoo from zero, in a wild
variety of environments from handhold embedded devices to top 10
supercomputers, from GNU/Linux, MacOS to Solaris/OpenIndiana and Cygwin.

Don't be pissed off if it couldn't be hacked in several hours to be
ported to ppc64.  That's life: anything worth doing will not be easy.


For the standards and documentation, yes, the recommended workflow had
better be carved into stone.  That's where things should be improved.

Good luck
Benda



[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 run full Java besids Android Runtime.

Thank you!
Benda


signature.asc
Description: PGP signature


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 if it is those that have more investment in doing
> so than the average IT Joe. By removing stable, we would be reducing the
> potential arguments for the few who do want to use Gentoo in that sort
> of environment. We would be becoming more of a niche distro.
>
> "Hey, lets try Gentoo - it's really configurable."
> "What's their stable policy? How often does it break?"
> "Stable? What's that?"

I agree with Sam.  I see several cases in academia (mainly astrophysics
and particle physics) that Gentoo stable is used and performs well.
Professtional use of Gentoo should be actively supported and even
advocated.

Benda


signature.asc
Description: PGP signature


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 be dropping it to maintainer-needed otherwise.

I am a daily user of matplotlib for scientific work.  Feel free to
assign it to the science project.  I will be happy to be its maintainer.

I will make a move on July 1.

Cheers,
Benda



[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.

3. It is really hard to whitelist/moderate in a transparent and
   objective way.


I take the intention of this proposal as that you would like to keep a
certain group of people out of your discussions.  If you personally want
to mute someone, it is straightforward to set up a blacklist in your
MTA/MUA.

I don't think a change is needed at the Gentoo infra level.

Yours,
Benda


signature.asc
Description: PGP signature


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
Description: PGP signature


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 as
> build time dependencies, but I think the upside (a build system where
> we don't have to worry about parallel make issues or portability)
> outweighs that.
>
> What do folks think here?

I would discourage it.  Making OpenRC build-depend on python introduces
unnecessary complexity that will undermine the portability of OpenRC
sooner or later.

After all OpenRC is a small program easy to build with a hand-written
Makefile.

Parallel make issues?  No problem let's just solve it.


Please, keep it simple.

Benda


signature.asc
Description: PGP signature


[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 @@ DESCRIPTION="The GNU Compiler Collection"
 HOMEPAGE="https://gcc.gnu.org/;
 RESTRICT="strip" # cross-compilers need controlled stripping
 
-inherit eutils fixheadtails flag-o-matic gnuconfig libtool multilib pax-utils 
toolchain-funcs versionator
+inherit eutils fixheadtails flag-o-matic gnuconfig libtool multilib pax-utils 
toolchain-funcs versionator prefix
 
 if [[ ${PV} == *_pre* ]] ; then
EGIT_REPO_URI="git://gcc.gnu.org/git/gcc.git"
@@ -1764,10 +1764,10 @@ toolchain_src_install() {
# Rather install the script, else portage with changing $FILESDIR
# between binary and source package borks things 
if ! is_crosscompile ; then
-   insinto "${DATAPATH}"
-   newins "${GCC_FILESDIR}"/awk/fixlafiles.awk-no_gcc_la 
fixlafiles.awk || die
-   exeinto "${DATAPATH}"
-   doexe "${GCC_FILESDIR}"/fix_libtool_files.sh || die
+   insinto "${DATAPATH#${EPREFIX}}"
+   newins "$(prefixify_ro 
"${GCC_FILESDIR}"/awk/fixlafiles.awk-no_gcc_la)" fixlafiles.awk || die
+   exeinto "${DATAPATH#${EPREFIX}}"
+   doexe "$(prefixify_ro "${GCC_FILESDIR}"/fix_libtool_files.sh)" 
|| die
doexe "${GCC_FILESDIR}"/c{89,99} || die
fi
 
-- 
2.8.3




[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 do the fun stripping stuff
env RESTRICT="" CHOST=${CHOST} prepstrip "${D}${BINPATH}"
is_crosscompile && \
-   env RESTRICT="" CHOST=${CHOST} prepstrip "${D}/${HOSTLIBPATH}"
+   env RESTRICT="" CHOST=${CHOST} prepstrip "${D}${HOSTLIBPATH}"
env RESTRICT="" CHOST=${CTARGET} prepstrip "${D}${LIBPATH}"
# gcc used to install helper binaries in lib/ but then moved to libexec/
[[ -d ${D}${PREFIX}/libexec/gcc ]] && \
-- 
2.8.3




[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 f54316c..941e37b 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -983,10 +983,10 @@ toolchain_src_configure() {
elif built_with_use --hidden --missing false 
${CATEGORY}/${needed_libc} crosscompile_opts_headers-only ; then
confgcc+=(
"${confgcc_no_libc[@]}"
-   --with-sysroot=${PREFIX}/${CTARGET}
+   --with-sysroot="${PREFIX}"/${CTARGET}
)
else
-   confgcc+=( --with-sysroot=${PREFIX}/${CTARGET} )
+   confgcc+=( 
--with-sysroot="${PREFIX}"/${CTARGET} )
fi
fi
 
@@ -1812,11 +1812,11 @@ toolchain_src_install() {
# Use gid of 0 because some stupid ports don't have
# the group 'root' set to gid 0.  Send to /dev/null
# for people who are testing as non-root.
-   chown -R root:0 "${D}"${LIBPATH} 2>/dev/null
+   chown -R root:0 "${D}${LIBPATH}" 2>/dev/null
 
# Move pretty-printers to gdb datadir to shut ldconfig up
local py 
gdbdir=/usr/share/gdb/auto-load${LIBPATH/\/lib\//\/$(get_libdir)\/}
-   pushd "${D}"${LIBPATH} >/dev/null
+   pushd "${D}${LIBPATH}" >/dev/null
for py in $(find . -name '*-gdb.py') ; do
local multidir=${py%/*}
insinto "${gdbdir}/${multidir}"
@@ -1862,16 +1862,16 @@ gcc_movelibs() {
 
local OS_MULTIDIR=$($(XGCC) ${multiarg} 
--print-multi-os-directory)
local MULTIDIR=$($(XGCC) ${multiarg} --print-multi-directory)
-   local TODIR=${D}${LIBPATH}/${MULTIDIR}
+   local TODIR="${D}${LIBPATH}"/${MULTIDIR}
local FROMDIR=
 
[[ -d ${TODIR} ]] || mkdir -p ${TODIR}
 
for FROMDIR in \
-   ${LIBPATH}/${OS_MULTIDIR} \
-   ${LIBPATH}/../${MULTIDIR} \
-   ${PREFIX}/lib/${OS_MULTIDIR} \
-   ${PREFIX}/${CTARGET}/lib/${OS_MULTIDIR}
+   "${LIBPATH}"/${OS_MULTIDIR} \
+   "${LIBPATH}"/../${MULTIDIR} \
+   "${PREFIX}"/lib/${OS_MULTIDIR} \
+   "${PREFIX}"/${CTARGET}/lib/${OS_MULTIDIR}
do
removedirs="${removedirs} ${FROMDIR}"
FROMDIR=${D}${FROMDIR}
@@ -2034,12 +2034,12 @@ gcc_slot_java() {
# Move random gcj files to compiler-specific directories
for x in libgcj.spec logging.properties ; do
x="${D}${PREFIX}/lib/${x}"
-   [[ -f ${x} ]] && mv -f "${x}" "${D}"${LIBPATH}/
+   [[ -f ${x} ]] && mv -f "${x}" "${D}${LIBPATH}"/
done
 
# Rename jar because it could clash with Kaffe's jar if this gcc is
# primary compiler (aka don't have the - extension)
-   cd "${D}"${BINPATH}
+   cd "${D}${BINPATH}"
[[ -f jar ]] && mv -f jar gcj-jar
 }
 
-- 
2.8.3




[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
+++ b/eclass/toolchain.eclass
@@ -2107,10 +2107,10 @@ toolchain_pkg_postrm() {
do_gcc_config
 
einfo "Running 'fix_libtool_files.sh ${GCC_RELEASE_VER}'"
-   /usr/sbin/fix_libtool_files.sh ${GCC_RELEASE_VER}
+   fix_libtool_files.sh ${GCC_RELEASE_VER}
if [[ -n ${BRANCH_UPDATE} ]] ; then
einfo "Running 'fix_libtool_files.sh 
${GCC_RELEASE_VER}-${BRANCH_UPDATE}'"
-   /usr/sbin/fix_libtool_files.sh 
${GCC_RELEASE_VER}-${BRANCH_UPDATE}
+   fix_libtool_files.sh ${GCC_RELEASE_VER}-${BRANCH_UPDATE}
fi
fi
 
-- 
2.8.3




[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 b/eclass/toolchain.eclass
index 17950c1..f54316c 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -93,7 +93,7 @@ fi
 
 export GCC_FILESDIR=${GCC_FILESDIR:-${FILESDIR}}
 
-PREFIX=${TOOLCHAIN_PREFIX:-/usr}
+PREFIX=${TOOLCHAIN_PREFIX:-${EPREFIX}/usr}
 
 if tc_version_is_at_least 3.4.0 ; then

LIBPATH=${TOOLCHAIN_LIBPATH:-${PREFIX}/lib/gcc/${CTARGET}/${GCC_CONFIG_VER}}
@@ -1267,7 +1267,7 @@ toolchain_src_configure() {
echo "${S}"/configure "${confgcc[@]}"
# Older gcc versions did not detect bash and re-exec itself, so force 
the
# use of bash.  Newer ones will auto-detect, but this is not harmeful.
-   CONFIG_SHELL="/bin/bash" \
+   CONFIG_SHELL="${EPREFIX}/bin/bash" \
bash "${S}"/configure "${confgcc[@]}" || die "failed to run configure"
 
# return to whatever directory we were in before
@@ -1703,11 +1703,11 @@ toolchain_src_install() {
if [[ -f ${CTARGET}-${x} ]] ; then
if ! is_crosscompile ; then
ln -sf ${CTARGET}-${x} ${x}
-   dosym ${BINPATH}/${CTARGET}-${x} \
+   dosym ${BINPATH#${EPREFIX}}/${CTARGET}-${x} \
/usr/bin/${x}-${GCC_CONFIG_VER}
fi
# Create versioned symlinks
-   dosym ${BINPATH}/${CTARGET}-${x} \
+   dosym ${BINPATH#${EPREFIX}}/${CTARGET}-${x} \
/usr/bin/${CTARGET}-${x}-${GCC_CONFIG_VER}
fi
 
@@ -1745,11 +1745,11 @@ toolchain_src_install() {
fi
fi
has noinfo ${FEATURES} \
-   && rm -r "${D}/${DATAPATH}"/info \
-   || prepinfo "${DATAPATH}"
+   && rm -r "${D}${DATAPATH}"/info \
+   || prepinfo "${DATAPATH#${EPREFIX}}"
has noman ${FEATURES} \
-   && rm -r "${D}/${DATAPATH}"/man \
-   || prepman "${DATAPATH}"
+   && rm -r "${D}${DATAPATH}"/man \
+   || prepman "${DATAPATH#${EPREFIX}}"
fi
# prune empty dirs left behind
find "${D}" -depth -type d -delete 2>/dev/null
@@ -1999,7 +1999,7 @@ copy_minispecs_gcc_specs() {
create_gcc_env_entry hardenednossp
fi
create_gcc_env_entry vanilla
-   insinto ${LIBPATH}
+   insinto ${LIBPATH#${EPREFIX}}
doins "${WORKDIR}"/specs/*.specs || die "failed to install specs"
# Build system specs file which, if it exists, must be a complete set of
# specs as it completely and unconditionally overrides the builtin 
specs.
@@ -2014,21 +2014,21 @@ gcc_slot_java() {
local x
 
# Move Java headers to compiler-specific dir
-   for x in "${D}"${PREFIX}/include/gc*.h "${D}"${PREFIX}/include/j*.h ; do
-   [[ -f ${x} ]] && mv -f "${x}" "${D}"${LIBPATH}/include/
+   for x in "${D}${PREFIX}"/include/gc*.h "${D}${PREFIX}"/include/j*.h ; do
+   [[ -f ${x} ]] && mv -f "${x}" "${D}${LIBPATH}"/include/
done
for x in gcj gnu java javax org ; do
if [[ -d ${D}${PREFIX}/include/${x} ]] ; then
-   dodir /${LIBPATH}/include/${x}
-   mv -f "${D}"${PREFIX}/include/${x}/* 
"${D}"${LIBPATH}/include/${x}/
-   rm -rf "${D}"${PREFIX}/include/${x}
+   dodir /${LIBPATH#${EPREFIX}}/include/${x}
+   mv -f "${D}${PREFIX}"/include/${x}/* 
"${D}${LIBPATH}"/include/${x}/
+   rm -rf "${D}${PREFIX}"/include/${x}
fi
done
 
if [[ -d ${D}${PREFIX}/lib/security ]] || [[ -d 
${D}${PREFIX}/$(get_libdir)/security ]] ; then
-   dodir /${LIBPATH}/security
-   mv -f "${D}"${PREFIX}/lib*/security/* "${D}"${LIBPATH}/security
-   rm -rf "${D}"${PREFIX}/lib*/security
+   dodir /${LIBPATH#${EPREFIX}}/security
+   mv -f "${D}${PREFIX}"/lib*/security/* "${D}${LIBPATH}"/security
+   rm -rf "${D}${PREFIX}"/lib*/security
fi
 
# Move random gcj files to compiler-specific directories
-- 
2.8.3




  1   2   >