[gentoo-dev] Re: [PATCH 1/4] autotools.eclass: don't inject -I${SYSROOT} to aclocal

[Mike Frysinger]

On 17 Jan 2022 11:09, Sam James wrote:
> When -I${SYSROOT} is injected, it'll override the default of -Im4, which
> results in trying to install macros to ${SYSROOT} (a sandbox violation)
> when they can't be found.
> 
> From aclocal(1):
> ```
>-I DIR add directory to search list for .m4 files
> 
>--install
>   copy third-party files to the first -I directory
> ```
> 
> The first directry is normally -Im4 if anything, whereas when injected
> (when ${SYSROOT} is defined), it ends up being ${SYSROOT}, not m4 (so
> we try to copy macros to somewhere outside of the build directory).

we should define the semantics we want and bring it upstream to get into
automake.  although it seems like ACLOCAL_PATH might work well enough
for us now to switch to that.

as a stop gap, it seems like the use of --install is pretty low ?  we're
cross-compiling about ~2.5k packages in CrOS every day and never seen a
failure here.  so the few packages which are running into troubles can
workaround it by setting AT_SYS_M4DIR right ?

> In EAPI 7+, this is almost always the case! We don't generally expect
> to find macros (particularly things like autoconf-archive) in ${SYSROOT}
> because that's for DEPEND-class dependencies, then they end up being
> copied in unnecessarily and wrongly.

i think this optimism is misplaced.  libraries often install m4 files
which is precisely why this logic is in here.
https://bugs.gentoo.org/677002#c10

deleting this check will break things.  prob more than we're fixing.
-mike


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: sys-apps/sandbox/

[Mike Frysinger]

On 28 Oct 2021 23:43, Andreas K. Huettel wrote:
> > checking whether the C compiler works...  * 
> > /var/tmp/portage/sys-apps/sandbox-2.25/work/sandbox-2.25/libsandbox/trace.c:_do_ptrace():83:
> >  failure (Function not implemented):
> >  * ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x, 
> > 0x): Function not implemented
> > configure: error: cannot run C compiled programs.
> > (and yes this is in qemu-alpha user space emulation)
> > 
> 
> Oops, sorry, this was the bump to sandbox-2.28 (?), not the stabilization.

if you have a bug to report, please use bugs.gentoo.org so things can stay
organized.
-mike


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] ebuild: allow RESTRICT=network-sandbox in ebuilds

[Mike Frysinger]

On 16 Jan 2018 23:32, Mike Gilbert wrote:
> On Tue, Jan 16, 2018 at 4:46 PM, Mike Frysinger wrote:
> > Some ebuilds are a bit hard to fix their use of the network in src
> > phases, so allow them to disable things.  This allows us to turn off
> > access by default and for the vast majority while we work out how to
> > fix the few broken packages.
> 
> If we are going to allow network sandboxing to be disabled in
> individual ebuilds, we should also allow the other sandboxes to be
> disabled for the same reasons. sys-apps/sandbox has been notoriously
> buggy, for example.

that sandbox can already be disabled dynamically in ebuilds as needed.
i don't really see a reason for it to be a RESTRICT value.
-mike


signature.asc
Description: Digital signature

[gentoo-portage-dev] [PATCH v2] ebuild: allow RESTRICT=network-sandbox in ebuilds

[Mike Frysinger]

From: Mike Frysinger <vap...@chromium.org>

Some ebuilds are a bit hard to fix their use of the network in src
phases, so allow them to disable things.  This allows us to turn off
access by default and for the vast majority while we work out how to
fix the few broken packages.

URL: https://crbug.com/731905
---
 man/ebuild.5   | 4 
 pym/portage/package/ebuild/doebuild.py | 3 ++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/man/ebuild.5 b/man/ebuild.5
index 42a0599fe3a9..1f2d4219e93e 100644
--- a/man/ebuild.5
+++ b/man/ebuild.5
@@ -689,6 +689,10 @@ binaries that are not compatible with debugedit.
 .I mirror
 files in \fBSRC_URI\fR will not be downloaded from the \fBGENTOO_MIRRORS\fR.
 .TP
+.I network\-sandbox
+Disables the network namespace for specific packages.
+Should not be used in the main Gentoo tree.
+.TP
 .I preserve\-libs
 Disables preserve\-libs for specific packages. Note than when a package is
 merged, RESTRICT=preserve\-libs applies if either the new instance or the
diff --git a/pym/portage/package/ebuild/doebuild.py 
b/pym/portage/package/ebuild/doebuild.py
index 0be148fd408e..f75f11a1a424 100644
--- a/pym/portage/package/ebuild/doebuild.py
+++ b/pym/portage/package/ebuild/doebuild.py
@@ -148,7 +148,8 @@ def _doebuild_spawn(phase, settings, actionmap=None, 
**kwargs):
kwargs['ipc'] = 'ipc-sandbox' not in settings.features or \
phase in _ipc_phases
kwargs['networked'] = 'network-sandbox' not in settings.features or \
-   phase in _networked_phases
+   phase in _networked_phases or \
+   'network-sandbox' in settings['PORTAGE_RESTRICT'].split()
 
if phase == 'depend':
kwargs['droppriv'] = 'userpriv' in settings.features
-- 
2.15.1

[gentoo-portage-dev] [PATCH] ebuild: allow RESTRICT=network-sandbox in ebuilds

[Mike Frysinger]

From: Mike Frysinger <vap...@chromium.org>

Some ebuilds are a bit hard to fix their use of the network in src
phases, so allow them to disable things.  This allows us to turn off
access by default and for the vast majority while we work out how to
fix the few broken packages.

URL: https://crbug.com/731905
---
 man/ebuild.5   | 4 
 pym/portage/package/ebuild/doebuild.py | 3 ++-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/man/ebuild.5 b/man/ebuild.5
index 42a0599fe3a9..a8fc3f86b68a 100644
--- a/man/ebuild.5
+++ b/man/ebuild.5
@@ -689,6 +689,10 @@ binaries that are not compatible with debugedit.
 .I mirror
 files in \fBSRC_URI\fR will not be downloaded from the \fBGENTOO_MIRRORS\fR.
 .TP
+.I network-sandbox
+Disables the network namespace for specific packages.
+Should not be used in the main Gentoo tree.
+.TP
 .I preserve\-libs
 Disables preserve\-libs for specific packages. Note than when a package is
 merged, RESTRICT=preserve\-libs applies if either the new instance or the
diff --git a/pym/portage/package/ebuild/doebuild.py 
b/pym/portage/package/ebuild/doebuild.py
index 0be148fd408e..f75f11a1a424 100644
--- a/pym/portage/package/ebuild/doebuild.py
+++ b/pym/portage/package/ebuild/doebuild.py
@@ -148,7 +148,8 @@ def _doebuild_spawn(phase, settings, actionmap=None, 
**kwargs):
kwargs['ipc'] = 'ipc-sandbox' not in settings.features or \
phase in _ipc_phases
kwargs['networked'] = 'network-sandbox' not in settings.features or \
-   phase in _networked_phases
+   phase in _networked_phases or \
+   'network-sandbox' in settings['PORTAGE_RESTRICT'].split()
 
if phase == 'depend':
kwargs['droppriv'] = 'userpriv' in settings.features
-- 
2.15.1

Re: [gentoo-dev] [PATCH 2/2] sys-libs/ncurses: Remove parallel econf logic

[Mike Frysinger]

On 20 Mar 2017 20:35, Michał Górny wrote:
> Remove the parallel econf logic that adds a lot of complexity for minor
> gain. It results in the output from different configure scripts being
> mixed in the build log, making it unreadable. It causes econf to be run
> in a subshell which is a PMS violation and can cause issues with some of
> package manager implementations.  Furthermore, the multijob parallel
> processes are interleaved with multilib-build logic which is unsupported
> and a very bad idea.

NAK.  you still haven't backed up your claims wrt to PMS, and this slows
things down significantly.
-mike


signature.asc
Description: Digital signature

[gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Mike Frysinger]

On 16 Mar 2017 10:38, Michał Górny wrote:
> Convert the usage of eblits in sys-devel/autoconf into an equivalent
> eclass. This makes the ebuilds more readable, more predictable and fixes
> compliance with stricter versions of the package manager (i.e. a future
> release of Portage).

obvious NAK until you sort out the open questions already raised about
the backwards breaking change you're trying to land in PMS.  the point
of having EAPI's in the first place is that we don't break them, but
change the behavior across new versions.

your patches aren't fixing actual bugs, just things you "don't like".
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Package up for grab

[Mike Frysinger]

On 03 Aug 2016 17:54, M wrote:

please fix your client to not top post or use html
-mike


signature.asc
Description: Digital signature

[gentoo-portage-dev] [PATCH v2] repoman: flag URIs using http:// when https:// is available

[Mike Frysinger]

---
v2
- add more sites
- check the trailing URL to filter false positives

 repoman/pym/repoman/modules/scan/ebuild/checks.py | 22 ++
 repoman/pym/repoman/modules/scan/ebuild/errors.py |  2 ++
 repoman/pym/repoman/qa_data.py|  4 +++-
 3 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/repoman/pym/repoman/modules/scan/ebuild/checks.py 
b/repoman/pym/repoman/modules/scan/ebuild/checks.py
index 15e225156db4..83f9362b7506 100644
--- a/repoman/pym/repoman/modules/scan/ebuild/checks.py
+++ b/repoman/pym/repoman/modules/scan/ebuild/checks.py
@@ -682,6 +682,28 @@ class EMakeParallelDisabledViaMAKEOPTS(LineCheck):
error = errors.EMAKE_PARALLEL_DISABLED_VIA_MAKEOPTS
 
 
+class UriUseHttps(LineCheck):
+   """Check that we use https:// for known good sites."""
+   repoman_check_name = 'uri.https'
+   _SITES = (
+   '([-._a-zA-Z0-9]*\.)?apache\.org',
+   # Most FDO sites support https, but not all (like tango).
+   # List the most common ones here for now.
+   
'((anongit|bugs|cgit|patchwork|people|specifications|www|xorg)\.)?freedesktop\.org',
+   '((bugs|dev|www)\.)?gentoo\.org',
+   'github\.(io|com)',
+   'savannah\.(non)?gnu\.org',
+   '((gcc|www)\.)?gnu\.org',
+   'curl\.haxx\.se',
+   '(sf|sourceforge)\.net',
+   '(www\.)?sourceware\.org',
+   )
+   # Try to anchor the end of the URL so we don't get false positives
+   # with http://github.com.foo.bar.com/.  Unlikely, but possible.
+   re = re.compile(r'.*\bhttp://(%s)(\s|["\'/]|$)' % r'|'.join(_SITES))
+   error = errors.URI_HTTPS
+
+
 class NoAsNeeded(LineCheck):
"""Check for calls to the no-as-needed function."""
repoman_check_name = 'upstream.workaround'
diff --git a/repoman/pym/repoman/modules/scan/ebuild/errors.py 
b/repoman/pym/repoman/modules/scan/ebuild/errors.py
index 3090de0d1a2c..14e47e35877e 100644
--- a/repoman/pym/repoman/modules/scan/ebuild/errors.py
+++ b/repoman/pym/repoman/modules/scan/ebuild/errors.py
@@ -47,3 +47,5 @@ USEQ_ERROR = (
'Ebuild calls deprecated useq function on line: %d')
 HASQ_ERROR = (
'Ebuild calls deprecated hasq function on line: %d')
+URI_HTTPS = (
+   'Ebuild uses http:// but should use https:// on line: %d')
diff --git a/repoman/pym/repoman/qa_data.py b/repoman/pym/repoman/qa_data.py
index 48ab389d086e..03711b6ed5d0 100644
--- a/repoman/pym/repoman/qa_data.py
+++ b/repoman/pym/repoman/qa_data.py
@@ -224,7 +224,8 @@ qahelp = {
"The ebuild makes use of an obsolete construct"),
"upstream.workaround": (
"The ebuild works around an upstream bug,"
-   " an upstream bug should be filed and tracked in 
bugs.gentoo.org")
+   " an upstream bug should be filed and tracked in 
bugs.gentoo.org"),
+   "uri.https": "URI uses http:// but should use https://;,
 }
 
 qacats = list(qahelp)
@@ -273,6 +274,7 @@ qawarnings = set((
"LIVEVCS.stable",
"LIVEVCS.unmasked",
"IUSE.rubydeprecated",
+   "uri.https",
 ))
 
 
-- 
2.8.2

Re: [gentoo-dev] Re: [PATCH 4/4] toolchain-funcs.eclass: Add helpful tc-is-{gcc,clang} wrappers

[Mike Frysinger]

On 24 Jun 2016 07:40, Michał Górny wrote:
> On Thu, 23 Jun 2016 21:32:34 -0400 Mike Frysinger wrote:
> > On 22 Jun 2016 22:06, Michał Górny wrote:
> > > +# @FUNCTION: tc-is-gcc
> > > +# @DESCRIPTION:
> > > +# Return true if the current compiler is pure GCC.  
> > 
> > "pure" doesn't make much sense and is just confusing
> > 
> > shouldn't this be a @RETURN instead of @DESCRIPTION ?  same for clang below.
> 
> I've followed suit with other functions in the eclass. They use @RETURN
> for stuff that is echoed, and @DESCRIPTION for exit codes.

right ... bash doesn't allow you to @RETURN a string
-mike


signature.asc
Description: Digital signature

[gentoo-dev] Re: [PATCH 2/4] toolchain-funcs.eclass: Assume CPP="$(tc-getCC) -E" when unset, #582822

[Mike Frysinger]

OK
-mike


signature.asc
Description: Digital signature

[gentoo-dev] Re: [PATCH 1/4] toolchain-funcs.eclass: Fix _tc-getPROG with multi-parameter defaults

[Mike Frysinger]

OK
-mike


signature.asc
Description: Digital signature

[gentoo-dev] Re: [PATCH 4/4] toolchain-funcs.eclass: Add helpful tc-is-{gcc,clang} wrappers

[Mike Frysinger]

On 22 Jun 2016 22:06, Michał Górny wrote:
> +# @FUNCTION: tc-is-gcc
> +# @DESCRIPTION:
> +# Return true if the current compiler is pure GCC.

"pure" doesn't make much sense and is just confusing

shouldn't this be a @RETURN instead of @DESCRIPTION ?  same for clang below.
-mike


signature.asc
Description: Digital signature

[gentoo-portage-dev] [PATCH] repoman: simplify wrapper for running locally

[Mike Frysinger]

Running the repoman program locally is a bit unreliable in its
detection.  Add a dedicated repoman.git program for people to
run directly if they want.
---
 repoman/.repoman_not_installed  |  0
 repoman/bin/repoman | 10 --
 repoman/bin/repoman.git | 37 +
 repoman/pym/repoman/__init__.py |  4 ++--
 repoman/setup.py| 10 --
 5 files changed, 39 insertions(+), 22 deletions(-)
 delete mode 100644 repoman/.repoman_not_installed
 create mode 100755 repoman/bin/repoman.git

diff --git a/repoman/.repoman_not_installed b/repoman/.repoman_not_installed
deleted file mode 100644
index e69de29bb2d1..
diff --git a/repoman/bin/repoman b/repoman/bin/repoman
index 7082a968f502..66211b26bc5e 100755
--- a/repoman/bin/repoman
+++ b/repoman/bin/repoman
@@ -25,16 +25,6 @@ try:
 except KeyboardInterrupt:
sys.exit(1)
 
-from os import path as osp
-here = osp.realpath(__file__)
-if osp.isfile(osp.join(osp.dirname(osp.dirname(here)), 
".repoman_not_installed")):
-   # Add the repoman subpkg
-   pym_path = osp.join(osp.dirname(osp.dirname(here)), "pym")
-   sys.path.insert(0, pym_path)
-   if osp.isfile(osp.join(osp.dirname(osp.dirname(osp.dirname(here))), 
".portage_not_installed")):
-   # Add the base portage pkg
-   pym_path = 
osp.join(osp.dirname(osp.dirname(osp.dirname(here))), "pym")
-   sys.path.insert(0, pym_path)
 
 import portage
 portage._internal_caller = True
diff --git a/repoman/bin/repoman.git b/repoman/bin/repoman.git
new file mode 100755
index ..67d4b17ba295
--- /dev/null
+++ b/repoman/bin/repoman.git
@@ -0,0 +1,37 @@
+#!/usr/bin/python -bO
+# Copyright 1999-2016 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+"""Run repoman from git using local modules/scripts."""
+
+from __future__ import print_function
+
+
+import os
+import sys
+
+
+def main(argv):
+   """The main entry point"""
+   source_root = 
os.path.dirname(os.path.dirname(os.path.realpath(__file__)))
+
+   # Add the repoman source root.
+   pympath = os.path.join(source_root, 'pym')
+   pythonpath = os.environ.get('PYTHONPATH')
+   if pythonpath is None:
+   pythonpath = pympath
+   else:
+   pythonpath = pympath + ':' + pythonpath
+   # Add the portage source root.
+   pythonpath += ':' + os.path.join(os.path.dirname(source_root), 'pym')
+   os.environ['PYTHONPATH'] = pythonpath
+
+   # Signal to some repoman code that we're not installed.
+   os.environ['REPOMAN_NOT_INSTALLED'] = 'true'
+
+   cmd = [os.path.join(source_root, 'bin', 'repoman')]
+   os.execvp(cmd[0], cmd + argv)
+
+
+if __name__ == '__main__':
+   main(sys.argv[1:])
diff --git a/repoman/pym/repoman/__init__.py b/repoman/pym/repoman/__init__.py
index 5f0f9f873b1b..40259e61f92a 100644
--- a/repoman/pym/repoman/__init__.py
+++ b/repoman/pym/repoman/__init__.py
@@ -1,6 +1,6 @@
 
-import os.path
+import os
 
 REPOMAN_BASE_PATH = os.path.join(os.sep, 
os.sep.join(os.path.realpath(__file__.rstrip("co")).split(os.sep)[:-3]))
 
-_not_installed = os.path.isfile(os.path.join(REPOMAN_BASE_PATH, 
".repoman_not_installed"))
+_not_installed = os.environ.get('REPOMAN_NOT_INSTALLED') == 'true'
diff --git a/repoman/setup.py b/repoman/setup.py
index 47ed15574de0..930d61060baf 100755
--- a/repoman/setup.py
+++ b/repoman/setup.py
@@ -145,11 +145,6 @@ class x_clean(clean):
print('removing %s symlink' % repr(conf_dir))
os.unlink(conf_dir)
 
-   pni_file = os.path.join(top_dir, '.repoman_not_installed')
-   if os.path.exists(pni_file):
-   print('removing %s' % repr(pni_file))
-   os.unlink(pni_file)
-
def clean_man(self):
man_dir = os.path.join(self.build_base, 'man')
if os.path.exists(man_dir):
@@ -350,11 +345,6 @@ class build_tests(x_build_scripts_custom):
print('Symlinking %s -> %s' % (conf_dir, conf_src))
os.symlink(conf_src, conf_dir)
 
-   # create $build_lib/../.repoman_not_installed
-   # to enable proper paths in tests
-   with open(os.path.join(self.top_dir, '.repoman_not_installed'), 
'w'):
-   pass
-
 
 class test(Command):
""" run tests """
-- 
2.8.2

Re: [gentoo-dev] Packages up for grabs

[Mike Frysinger]

please avoid html e-mails
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place

[Mike Frysinger]

On 21 May 2016 17:08, Amadeusz Żołnowski wrote:
> Mike Frysinger <vap...@gentoo.org> writes:
> >> The same "sed -i" is used. I have some configs to edit in place in
> >> src_prepare(). It's easier with awk rather than sed.
> >
> > again, provide an example.  one or two uncommon use cases doesn't justify
> > being added to eutils.
> 
> See rebar.eclass review where it is used. Later ejabberd ebuild I'm
> going to add uses it as well.

neither of those are terribly compelling and can be written in sed.
you want to do a match & replace in that just as easily.  roughly:
sed -i \
-e '/{[[:space:]]*deps[[:space:]]*,\/,\/}/{s:.*:{deps, []}:}' \
foo

> This function is too generic to be in
> rebar.eclass, so I have decided to move it to eutils. What is the
> problem with adding it to eutils?

because no one else is using it or cares about it.  we've gotten by
for more than 10 years at this point w/out someone asking for this.

if you really want it in rebar, then just DEPEND on gawk and use the
inplace flag in your code.  then there's no need for eawk anywhere.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place

[Mike Frysinger]

On 20 May 2016 21:09, Amadeusz Żołnowski wrote:
> Mike Frysinger <vap...@gentoo.org> writes:
> > On 18 May 2016 22:25, aide...@gentoo.org wrote:
> >> awk doesn't have the -i option like sed and if editing file in place is
> >> desired, additional steps are required. eawk uses tmp file to make it
> >> look to the caller editing happens in place.
> >
> > what's your real use case ?  i've never once thought "man, i wish i could
> > run an awk script and modify a file in place".  and i write awk most days.
> 
> The same "sed -i" is used. I have some configs to edit in place in
> src_prepare(). It's easier with awk rather than sed.

again, provide an example.  one or two uncommon use cases doesn't justify
being added to eutils.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH] flag-o-matic.eclass: bugfix for get-flag()

[Mike Frysinger]

On 16 May 2016 14:17, rindeal wrote:
> So this is what it looks like now:

still missing tests.  see eclass/tests/flag-o-matic.sh.

> -   local f var findflag="$1"
> -
> -   # this code looks a little flaky but seems to work for
> -   # everything we want ...
> -   # for example, if CFLAGS="-march=i686":
> -   # `get-flag -march` == "-march=i686"
> -   # `get-flag march` == "i686"
> +   local var pattern="${1}"

drop the braces for builtin vars

> for var in $(all-flag-vars) ; do
> -   for f in ${!var} ; do
> -   if [ "${f/${findflag}}" != "${f}" ] ; then
> -   printf "%s\n" "${f/-${findflag}=}"
> +   local i flags=( ${!var} )
> +   for (( i=${#flags[@]}-1; i>=0; i-- )) ; do

omitting spaces doesn't make code faster, it just makes it unreadable.
for (( i = ${#flags[@]} - 1; i >= 0; --i )) ; do

stick a comment above this for loop explaining why we walk backwards.

> +   local needle="-${pattern#-}" # force dash on

avoid inline comments and make them complete sentences.
# Make sure we anchor to the leading dash.
local needle="-${pattern#-}"

> +   local haystack="${flags[i]%%=*}" # we're comparing flags, not 
> values

it's a bit easier to read if you unpack the flag explicitly.
local flag=${flags[i]}

> +   if [[ ${haystack##${needle}} == '' ]] ; then

use a -z test instead of comparing to ''
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place

[Mike Frysinger]

On 18 May 2016 22:25, aide...@gentoo.org wrote:
> awk doesn't have the -i option like sed and if editing file in place is
> desired, additional steps are required. eawk uses tmp file to make it
> look to the caller editing happens in place.

what's your real use case ?  i've never once thought "man, i wish i could
run an awk script and modify a file in place".  and i write awk most days.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH] eutils.eclass: Add awk wrapper - eawk - edit file in place

[Mike Frysinger]

On 20 May 2016 02:16, Mart Raudsepp wrote:
> I would like if such a function would explicitly document that calling
> this function means the caller should DEPEND on an awk provider.
> Similarly, I would like that all ebuild that call 'sed' actually DEPEND
> on sed, not just half of them.
> I would also like that no ebuild would assume packages in @system to be
> present, beyond those dictated by PMS (unpackers and such).

this is all a terrible terrible idea and has been hashed/explained a
number of times on this list.  have you ever tried looking at the tools
configure scripts run ?
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev][PATCH] dev-lang/go-1.6.2: enable go-bootstrap tarball for ppc64le #581278

[Mike Frysinger]

On 28 Apr 2016 13:28, Leno Hou wrote:
> --- a/dev-lang/go/go-1.6.2.ebuild
> +++ b/dev-lang/go/go-1.6.2.ebuild
> @@ -88,6 +88,16 @@ go_arch()
>   case "${portage_arch}" in
>   x86)echo 386;;
>   x64-*)  echo amd64;;
> + ppc64)
> + case "$(tc-endian $@)" in

the quote nesting is incorrect.  you want:
case $(tc-endian "$@") in

> + little)
> + echo ppc64le
> + ;;
> + big)
> + echo ppc64
> + ;;
> + esac
> + ;;

up to William, but seems like a one liner would be fine:
[[ $(tc-endian "$@") == "big" ]] && echo ppc64 || echo ppc64le
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev][PATCH v1 ] sys-fs/hfsplusutils with gcc-5: blockiter.c:148:8: error: redefinition of blockiter_curr #580620

[Mike Frysinger]

On 23 Apr 2016 11:39, David Seifert wrote:

please don't top post

> I generally prefer using -std=gnu89 instead of -fgnu89-inline, as GCC might 
> change some C11 semantics later on. To me -std=gnu89 seems more robust.

perhaps, but other than gnu-inline behavior, it seems to be fine.
if we hit another build issue, we can re-evaluate then.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev][PATCH v1 ] sys-fs/hfsplusutils with gcc-5: blockiter.c:148:8: error: redefinition of blockiter_curr #580620

[Mike Frysinger]

On 22 Apr 2016 03:57, Leno Hou wrote:
> +-extern inline UInt32 blockiter_curr(blockiter *b)
> +-{
> +-return b->e->start_block + b->block;
> +-}
> +-
> +-
> ++extern inline UInt32 blockiter_curr(blockiter *b);

i don't think that's how you want to handle extern inline.
it doesn't make sense when it's declared this way as there
is no actual body for gcc to optimisitcally inline.

instead, we should go with what Ubuntu/Debian have: use the
-fgnu89-inline flag to build since those are the semantics
this code expects.  i've pushed that fix now.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev][PATCH v2 2/2] ERROR: sys-apps/attr: unable to read SONAME from libattr.so #580792

[Mike Frysinger]

thanks, i've added elibtoolize calls to acl & attr now
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d9e18bcb8f8bcaa6b3e5543caf16a684e7dacd21
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev][PATCH v2 1/2] eclass/libtool: fix unable read SONAME for ppc64le #580792

[Mike Frysinger]

On 22 Apr 2016 03:44, Leno Hou wrote:
>  2) The problem is due to the wrong $LD="ld -m elf64ppc" when link.
>   This patch sets $LD="ld -m elf64lppc" in m4/libtool.m4 on ppc64le.

i'm looking at the upstream libtool project and i'm not seeing
these changes in there.  have you sent patches to them to update
libtool ?  otherwise, all packages will continue to be created
with bad versions in them ...

what upstream has right now is:
  if AC_TRY_EVAL(ac_compile); then
case `/usr/bin/file conftest.o` in
  *32-bit*)
case $host in
...
  powerpc64le-*linux*)
LD="${LD-ld} -m elf32lppclinux"
;;
  powerpc64-*linux*)
LD="${LD-ld} -m elf32ppclinux"
;;
...
  *64-bit*)
case $host in
...
  powerpcle-*linux*)
LD="${LD-ld} -m elf64lppc"
;;
  powerpc-*linux*)
LD="${LD-ld} -m elf64ppc"
;;
...

your 2.4.2 patch makes sense in that it had no LE support, so you
need to add the tuple matching.  however, the 2.4.4 & 2.4.6 patches
are applying to libtool versions that know how to handle LE.

keep in mind that the logic here is just for handling mismatch in
the expected bitness and the tuple.  i.e. when you're using a tuple
like powerpc-linux-gnu (which is normally 32bit) but you're actually
producing 64-bit code.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH v1] eclass/toolchain-bintuils: enable targets powerpc-linux-gnu for ppc64

[Mike Frysinger]

On 21 Apr 2016 13:16, Leno Hou wrote:
> On Wed, Apr 20, 2016 at 11:07 PM, Mike Frysinger wrote:
> > On 20 Apr 2016 13:52, Leno Hou wrote:
> > > Authored-by: Linda Jiang <linda.q...@gmail.com>
> > > ---
> > >  eclass/toolchain-binutils.eclass | 1 +
> > >  1 file changed, 1 insertion(+)
> >
> > when you submit a patch that is not extremely obvious, you must provide
> > details/justification in the commit message.  otherwise we're forced to
> > try and guess what/why it is you want to do things, and ultimately we
> > tend to start of just saying "no".
> >
> 
> Sorry, We describes details/justification in  Gentoo Bugzilla#580614
> <https://bugs.gentoo.org/show_bug.cgi?id=580614>. Explain here again.

that bug hadn't been reassigned yet to toolchain@ so i didn't see it.
i'll follow up there.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH v1] eclass/toolchain-bintuils: enable targets powerpc-linux-gnu for ppc64

[Mike Frysinger]

On 20 Apr 2016 13:52, Leno Hou wrote:
> Authored-by: Linda Jiang 
> ---
>  eclass/toolchain-binutils.eclass | 1 +
>  1 file changed, 1 insertion(+)

when you submit a patch that is not extremely obvious, you must provide
details/justification in the commit message.  otherwise we're forced to
try and guess what/why it is you want to do things, and ultimately we
tend to start of just saying "no".

> --- a/eclass/toolchain-binutils.eclass
> +++ b/eclass/toolchain-binutils.eclass
> @@ -271,6 +271,7 @@ toolchain-binutils_src_configure() {
>   # We used to do it for everyone, but it's slow on 32bit arches. #438522
>   case $(tc-arch) in
>   ppc|sparc|x86) myconf+=( --enable-64-bit-bfd ) ;;
> + ppc64) myconf+=( --enable-targets="powerpc-linux-gnu" ) ;;
>   esac

why ?  we don't normally do this (as you can see in the file, there is no
other arch-specific handling like this).  instead, binutils itself handles
things by selecting a default set of supported targets based on the active
host.  and when i glance in there, this seems to already be done for you.

bfd/config.bfd:
  powerpc64-*-elf* | powerpc-*-elf64* | powerpc64-*-linux* | \
  powerpc64-*-*bsd*)
targ_defvec=powerpc_elf64_vec
targ_selvecs="powerpc_elf64_le_vec powerpc_elf32_vec powerpc_elf32_le_vec 
rs6000_xcoff_vec rs6000_xcoff64_vec rs6000_xcoff64_aix_vec"
want64=true
;;
  powerpc64le-*-elf* | powerpcle-*-elf64* | powerpc64le-*-linux* | \
  powerpc64le-*-*bsd*)
targ_defvec=powerpc_elf64_le_vec
targ_selvecs="powerpc_elf64_vec powerpc_elf32_le_vec powerpc_elf32_vec 
rs6000_xcoff_vec rs6000_xcoff64_vec rs6000_xcoff64_aix_vec"
want64=true
;;

ld/configure.tgt:
powerpc*-*-elf* | powerpc*-*-eabi* | powerpc*-*-sysv* \
  | powerpc*-*-linux* | powerpc*-*-netbsd* | powerpc*-*-openbsd* \
  | powerpc*-*-solaris* | powerpc*-*-kaos* | powerpc*-*-vxworks*)
 case "${targ}" in
*64*)   targ_emul=elf64ppc
targ_extra_emuls="elf32ppc elf32ppclinux elf32ppcsim"
targ_extra_libpath="elf32ppc elf32ppclinux"
td=tdir_elf32ppc
case "${targ}" in
powerpc*le-*) td=tdir_elf32lppc;;
esac
eval ${td}=`echo "${targ_alias}" | sed -e 's/64//'`
eval ${td}linux=\$${td}
eval ${td}sim=\$${td}
;;

and indeed, when i query a default ppc64 linker, it says it already
supports both 32bit & 64bit targets:
$ powerpc64-unknown-linux-gnu-ld --help | grep supported
powerpc64-unknown-linux-gnu-ld: supported targets: elf64-powerpc 
elf64-powerpcle elf32-powerpc elf32-powerpcle aixcoff-rs6000 aixcoff64-rs6000 
aix5coff64-rs6000 elf64-little elf64-big elf32-little elf32-big plugin srec 
symbolsrec verilog tekhex binary ihex
powerpc64-unknown-linux-gnu-ld: supported emulations: elf64ppc elf32ppc 
elf32ppclinux elf32ppcsim

it would have to of course in order for biarch support (which works)
which is how we build 64-bit kernels in a 32-bit userland.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH v1][ 1/8] app-text/opensp: Fix ppc64le configure problem

[Mike Frysinger]

On 19 Apr 2016 22:12, Leno Hou wrote:
> --- /dev/null
> +++ b/app-text/opensp/files/opensp-1.5.2-configure-with-ppc64le.patch
> @@ -0,0 +1,26 @@
> +--- configure.orig   2016-04-09 16:24:17.507053635 +
>  configure2016-04-09 16:25:41.851918142 +
> +@@ -4947,6 +4947,9 @@
> + ppc64-*linux*|powerpc64-*linux*)
> +   LD="${LD-ld} -m elf32ppclinux"
> +   ;;
> ++ppc64le-*linux*|powerpc64le-*linux*)
> ++  LD="${LD-ld} -m elf32lppclinux"
> ++  ;;

you appear to be patching libtool code.  this should be in libtool
itself. if it's a common issue, we'll want to leverage elibtoolize
here.  make a patch and stick it in eclass/ELT-patches/ppc64le/,
and then update the libtool.eclass file to apply those.  then update
opensp to call the elibtoolize function in src_prepare.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] glibc 2.23 and willfully breaking stuff

[Mike Frysinger]

On 19 Apr 2016 04:02, Anthony G. Basile wrote:
> On 4/19/16 1:41 AM, Mike Frysinger wrote:
> > i waited until the known bugs died down.  i don't have access to a
> > tinderbox system myself.
> 
> you didn't notice that coreutils and systemd/udev/eudev broke?

i had pushed the coreutils issue upstream, but i thought it was fixed
already (via configure checks).  i don't run those other packages.

> but a heads up would have been useful

certainly.  i usually do it based on how much on an impat a change
will have.  i didn't think this would spawn as many bugs as it had
(since the incoming rate had slowed/stopped), but i misjudged.

> > not today, but as i said, we want to move multiple libraries (at least
> > glibc, uClibc, musl, and bionic) in that direction.  the current behavior
> > violates the POSIX standard.
> 
> i took a look at opengroup.org and it seems posix is silent on the
> matter.

POSIX does not permit sys/types.h inclusion to export things it doesn't
define.  since it doesn't define major/minor/makedev, including them in
the export is a standards violation.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] glibc 2.23 and willfully breaking stuff

[Mike Frysinger]

On 19 Apr 2016 08:15, Michał Górny wrote:
> On Tue, 19 Apr 2016 01:41:06 -0400 Mike Frysinger wrote:
> > On 19 Apr 2016 04:21, Mart Raudsepp wrote:
> > > Ühel kenal päeval, E, 18.04.2016 kell 12:38, kirjutas Mike Frysinger:  
> > > > On 16 Apr 2016 09:23, Patrick Lauer wrote:  
> > > > > So why on earth are we applying a random patch that upstream is not
> > > > > using  
> > > > 
> > > > not everyone uses glibc, and glibc *is* moving in this
> > > > direction.  Gentoo
> > > > is simply accelerating the change ... otherwise glibc will take
> > > > longer to do the actual migration.  
> > > 
> > > You don't need to break everyone's ~arch for dubious glibc benefits,
> > > which could be done by a p.masked version and a tinderbox run.
> > > I am not your tinderbox dummy having to waste time on this to maintain
> > > my own ~arch stuff.  
> > 
> > i waited until the known bugs died down.  i don't have access to a
> > tinderbox system myself.
> 
> Cut the nonsense. You clearly didn't even test that glibc version
> on a single system. If you did, you'd notice the core system packages
> failing to build.

i know it's asking a lot of you, but you should refrain from making claims
that not only do you obviously have no idea about but can also be trivially
refuted.  i run glibc versions starting before i commit them to the tree
and build/test packages against it constantly.  this box has built hundreds
of packages and if you look at the git tree, i fixed a number of packages
before anyone even saw the breakage.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] glibc 2.23 and willfully breaking stuff

[Mike Frysinger]

On 19 Apr 2016 04:21, Mart Raudsepp wrote:
> Ühel kenal päeval, E, 18.04.2016 kell 12:38, kirjutas Mike Frysinger:
> > On 16 Apr 2016 09:23, Patrick Lauer wrote:
> > > So why on earth are we applying a random patch that upstream is not
> > > using
> > 
> > not everyone uses glibc, and glibc *is* moving in this
> > direction.  Gentoo
> > is simply accelerating the change ... otherwise glibc will take
> > longer to do the actual migration.
> 
> You don't need to break everyone's ~arch for dubious glibc benefits,
> which could be done by a p.masked version and a tinderbox run.
> I am not your tinderbox dummy having to waste time on this to maintain
> my own ~arch stuff.

i waited until the known bugs died down.  i don't have access to a
tinderbox system myself.

> > packages failing to build under glibc already
> > fail to build in other environments.
> 
> That is simply not true

except for the part where it is.  highlighting one system where it's
working for you doesn't mean all systems behave that way.  there's even
an autoconf macro specifically to deal with this and has been for years.
they wouldn't have written & deployed it for fun.

> at least not to the extent you make it sound.

not today, but as i said, we want to move multiple libraries (at least
glibc, uClibc, musl, and bionic) in that direction.  the current behavior
violates the POSIX standard.

> Why are all the concerns raised at e.g
> https://bugs.freedesktop.org/show_bug.cgi?id=94231 not resolved then?

what exactly are you expecting here ?  i'm not an X.org dev.  i can't
fix code in that project for them.  all the questions posed have been
answered in the bug.  it's merely waiting for them to actually commit
code.

> Over there you even told you won't be including this patch in Gentoo,
> but get it trickled in from upstream once they judge it as good to go.

no idea where you're getting reading this.  i never said that.

> Instead you go ahead and unmask this without removing the gentoo
> specific sysmacros header removal, knowing FULLY WELL that you break
> ~arch for a lot of things

again, no.  read what i actually said, and read the actual bug open on
the topic.  most of the packages i was aware of were fixed, and there
were only like 2 or 3 left assigned to projects/devs who are not me.
once things moved into ~arch, we started getting more bug reports, not
before.

> Even todays git of man-pages tells that including sys/types.h is
> sufficient and the correct thing to do to get makedev/major/minor.

and we've already been discussing fixing that.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] glibc 2.23 and willfully breaking stuff

[Mike Frysinger]

On 16 Apr 2016 09:23, Patrick Lauer wrote:
> So why on earth are we applying a random patch that upstream is not
> using

not everyone uses glibc, and glibc *is* moving in this direction.  Gentoo
is simply accelerating the change ... otherwise glibc will take longer to
do the actual migration.  packages failing to build under glibc already
fail to build in other environments.

> *and* unleashing it on ~arch without any of the usual precautions
> like masking the package until some of the issues have been smoked out?

it was masked for a while, some bugs were fixed, but no new ones were
really being found.  so in the absence of data showing a problem,
unmasking is normal.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH 00/21] gen_usr_ldscript: migrate away from a sep-/usr by default

[Mike Frysinger]

On 01 Apr 2016 20:00, Alexis Ballier wrote:
> On Friday, April 1, 2016 3:58:18 AM CEST, Mike Frysinger wrote:
> >>> ...
> >> lemme look it up for you then:
> >> https://wiki.gentoo.org/wiki/Council_decisions
> >> 
> >> systems with separate /usr should be supported. However, users 
> >> shouldn't be 
> >> constrained from using software which doesn't support that. -- 04/2012 
> >> meeting ...
> >
> > "being supported" != "enabled by default".  so no, i still don't see any
> > requirement in anything you've cited that this be turned on by default.
> 
> you're right, but you know, before you claimed the contrary of what was 
> voted and then decided to argue whether a 4 years old council decision 
> applies or not here, my point was, and still is, that such council 
> decisions make me think you're confusing what *you* want and what *we* (as 
> a project) want for this case

i see no significant number of people clamoring for this as the default.
the bug that started this has everyone on board for changing the default.
it's really no different either from the install process today: a stage3
cannot be unpacked & booted directly.  a user must configure it before it
can actually be used.  if that means enabling USE=sep-usr, then so be it.
there's no reason to force this legacy behavior on the majority of people
when a split-/usr is uncommon.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH 00/21] gen_usr_ldscript: migrate away from a sep-/usr by default

[Mike Frysinger]

On 31 Mar 2016 21:09, Alexis Ballier wrote:
> On Thursday, March 31, 2016 8:19:52 PM CEST, Mike Frysinger wrote:
> > On 31 Mar 2016 19:00, Alexis Ballier wrote:
> >> On Thursday, March 31, 2016 6:07:28 PM CEST, Mike Frysinger wrote:
> >>> On 31 Mar 2016 16:05, Alexis Ballier wrote: ...
> >> 
> >> i dont think anybody expects you to post tree-wide conversion patches to 
> >> -dev ml :)
> >> 
> >> but i also dont think it is a good idea to leave the toolchain-funcs 
> >> version around, and if you want to drop it, you'll have to 
> >> fill bugs to let 
> >> ppl know, which is probably more work than adding 8 chars to an inherit 
> >> line that can be automated
> >
> > sure -- backwards compat won't be dropped until we're confident everyone
> > has migrated over
> 
> ... which introduces a mess to track what has been converted and what not 
> while it can be done once and for good

not really.  a simple grep in the tree for the single func being dropped
is fairly trivial.

> >>> ...
> >> not sure if this was phrased as such, but I seem to recall a council 
> >> decision stating that separate /usr should be made easy to users unless 
> >> this causes serious issues; thus, no, I don't think that is 
> >> the behavior we 
> >> want :) ...
> >
> > pretty sure the decision was that it's not required to be supported.
> 
> lemme look it up for you then:
> https://wiki.gentoo.org/wiki/Council_decisions
> 
> systems with separate /usr should be supported. However, users shouldn't be 
> constrained from using software which doesn't support that. -- 04/2012 
> meeting
> 
> The council has voted in favour of a separate /usr being supported
> (5 yes, 1 no vote).
> 
> >  and
> > regardless of that, i don't see the default behavior of being off as being
> > contra "easy to use".
> 
> but you're right there, it doesn't make it hard to use, just not working 
> out of the box, which is already debatable; however, with eudev being the 
> default I don't think there is anything preventing it atm with a default 
> setup, but i might certainly stand corrected there

"being supported" != "enabled by default".  so no, i still don't see any
requirement in anything you've cited that this be turned on by default.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH 00/21] gen_usr_ldscript: migrate away from a sep-/usr by default

[Mike Frysinger]

On 31 Mar 2016 21:13, Alexis Ballier wrote:
> On Thursday, March 31, 2016 8:20:45 PM CEST, Mike Frysinger wrote:
> > On 31 Mar 2016 19:03, Alexis Ballier wrote:
> >> On Thursday, March 31, 2016 6:08:52 PM CEST, Mike Frysinger wrote:
> >>> On 31 Mar 2016 10:12, Mike Gilbert wrote: ...
> >> 
> >> unless you symlink /bin to /usr/bin, moving binaries around has wider 
> >> implications than sep-usr
> >
> > no valid package will be affected.  if you're hardcoding `/bin/foo`, then
> > you're doing it wrong already and that's your fault.
> 
> since when '#! /bin/sh' is invalid at the top of a shell script ? or even 
> execv deprecated ?

there are exceptions for a few very well known programs, but a few shebangs
does not mean supporting `/bin/cut` or `/bin/kmod` is required.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH 00/21] gen_usr_ldscript: migrate away from a sep-/usr by default

[Mike Frysinger]

On 31 Mar 2016 19:03, Alexis Ballier wrote:
> On Thursday, March 31, 2016 6:08:52 PM CEST, Mike Frysinger wrote:
> > On 31 Mar 2016 10:12, Mike Gilbert wrote:
> >> On Wed, Mar 30, 2016 at 7:58 PM, Mike Frysinger 
> >> <vap...@gentoo.org> wrote: ...
> >
> > i think we can scope it currently for libs (and any data files they need),
> > but i don't see it being a bad thing to leverage it for /bin progs.
> 
> unless you symlink /bin to /usr/bin, moving binaries around has wider 
> implications than sep-usr

no valid package will be affected.  if you're hardcoding `/bin/foo`, then
you're doing it wrong already and that's your fault.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH 00/21] gen_usr_ldscript: migrate away from a sep-/usr by default

[Mike Frysinger]

On 31 Mar 2016 19:00, Alexis Ballier wrote:
> On Thursday, March 31, 2016 6:07:28 PM CEST, Mike Frysinger wrote:
> > On 31 Mar 2016 16:05, Alexis Ballier wrote:
> >> On Thursday, March 31, 2016 1:58:19 AM CEST, Mike Frysinger wrote:
> >>> All ebuilds that call gen_usr_ldscript today will migrate to this and
> >>> will allow people to move away from installing things into /.  For the
> >>> systems that want to have a split-/usr partition, they can turn on this
> >>> USE flag across their system.
> >> 
> >> Your patchset seems to be missing some ebuilds in that regard: expat and 
> >> sys-freebsd/* come to mind.
> >
> > i did not do a full migration as i got bored, but i did do enough to show
> > it in action.  the current method does not require all be converted at the
> > same time though, so it can be left up to maintainers of relevant packages
> > to do the change over themselves.
> 
> i dont think anybody expects you to post tree-wide conversion patches to 
> -dev ml :)
> 
> but i also dont think it is a good idea to leave the toolchain-funcs 
> version around, and if you want to drop it, you'll have to fill bugs to let 
> ppl know, which is probably more work than adding 8 chars to an inherit 
> line that can be automated

sure -- backwards compat won't be dropped until we're confident everyone
has migrated over

> >>> This also allows us to mask the flag on many targets where it doesn't
> >>> make sense (like most prefix setups) and where we don't want to support
> >>> it at all.
> >> 
> >> It should be noted that, unless I missed something, the default settings 
> >> will *not anymore* allow sep-usr after this patchset (sep-usr 
> >> useflag will 
> >> be disabled). This should be advertised more (a news item?) or simply 
> >> sep-usr added to make.defaults. The latter will also enable busybox's 
> >> sep-usr support.
> >
> > the patchset allows for some targets (notably Linux systems) to control
> > whether the flag is enabled.  it is turned off by default and i think
> > that's the behavior we want.  i have not forced enabled it for any target
> > but maybe the prefix/darwin guys will want to do that.
> 
> not sure if this was phrased as such, but I seem to recall a council 
> decision stating that separate /usr should be made easy to users unless 
> this causes serious issues; thus, no, I don't think that is the behavior we 
> want :)

pretty sure the decision was that it's not required to be supported.  and
regardless of that, i don't see the default behavior of being off as being
contra "easy to use".
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH 00/21] gen_usr_ldscript: migrate away from a sep-/usr by default

[Mike Frysinger]

On 31 Mar 2016 10:12, Mike Gilbert wrote:
> On Wed, Mar 30, 2016 at 7:58 PM, Mike Frysinger <vap...@gentoo.org> wrote:
> > To make forward progress on bug 417451, introduce a new sep-usr eclass
> > that will hold all logic related to having a separate /usr.  For now,
> > this is just the gen_usr_ldscript function and a new USE=sep-usr flag.
> 
> Seems like a decent idea.
> 
> Before this flag gets added, should we define some bounds? I just
> don't want to see this flag get abused by using it to move other files
> around randomly, like moving things from /bin to /usr/bin, etc.

i think we can scope it currently for libs (and any data files they need),
but i don't see it being a bad thing to leverage it for /bin progs.

> > All ebuilds that call gen_usr_ldscript today will migrate to this and
> > will allow people to move away from installing things into /.  For the
> > systems that want to have a split-/usr partition, they can turn on this
> > USE flag across their system.
> 
> So the sep-usr flag will be disabled by default? That's going to
> trigger a change from the current state, and will definitely need to
> be announced.

correct.  i can put together a news item.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH 00/21] gen_usr_ldscript: migrate away from a sep-/usr by default

[Mike Frysinger]

On 31 Mar 2016 16:05, Alexis Ballier wrote:
> On Thursday, March 31, 2016 1:58:19 AM CEST, Mike Frysinger wrote:
> > All ebuilds that call gen_usr_ldscript today will migrate to this and
> > will allow people to move away from installing things into /.  For the
> > systems that want to have a split-/usr partition, they can turn on this
> > USE flag across their system.
> 
> Your patchset seems to be missing some ebuilds in that regard: expat and 
> sys-freebsd/* come to mind.

i did not do a full migration as i got bored, but i did do enough to show
it in action.  the current method does not require all be converted at the
same time though, so it can be left up to maintainers of relevant packages
to do the change over themselves.

> > This also allows us to mask the flag on many targets where it doesn't
> > make sense (like most prefix setups) and where we don't want to support
> > it at all.
> 
> It should be noted that, unless I missed something, the default settings 
> will *not anymore* allow sep-usr after this patchset (sep-usr useflag will 
> be disabled). This should be advertised more (a news item?) or simply 
> sep-usr added to make.defaults. The latter will also enable busybox's 
> sep-usr support.

the patchset allows for some targets (notably Linux systems) to control
whether the flag is enabled.  it is turned off by default and i think
that's the behavior we want.  i have not forced enabled it for any target
but maybe the prefix/darwin guys will want to do that.
-mike


signature.asc
Description: Digital signature

[gentoo-dev] [PATCH 15/21] sys-libs/libcap: switch to sep-usr eclass

[Mike Frysinger]

---
 sys-libs/libcap/libcap-2.24-r2.ebuild | 4 ++--
 sys-libs/libcap/libcap-2.25.ebuild| 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/sys-libs/libcap/libcap-2.24-r2.ebuild 
b/sys-libs/libcap/libcap-2.24-r2.ebuild
index 1585662..6c8f163 100644
--- a/sys-libs/libcap/libcap-2.24-r2.ebuild
+++ b/sys-libs/libcap/libcap-2.24-r2.ebuild
@@ -4,7 +4,7 @@
 
 EAPI="4"
 
-inherit eutils multilib multilib-minimal toolchain-funcs pam
+inherit eutils multilib multilib-minimal toolchain-funcs pam sep-usr
 
 DESCRIPTION="POSIX 1003.1e capabilities"
 HOMEPAGE="http://www.friedhoff.org/posixfilecaps.html;
@@ -16,7 +16,7 @@ SLOT="0"
 KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc 
x86 ~amd64-linux ~arm-linux ~ia64-linux ~x86-linux"
 IUSE="pam static-libs"
 
-RDEPEND=">=sys-apps/attr-2.4.47-r1[${MULTILIB_USEDEP}]
+RDEPEND=">=sys-apps/attr-2.4.47-r1[${MULTILIB_USEDEP},sep-usr?]
pam? ( virtual/pam )"
 DEPEND="${RDEPEND}
sys-kernel/linux-headers"
diff --git a/sys-libs/libcap/libcap-2.25.ebuild 
b/sys-libs/libcap/libcap-2.25.ebuild
index fc4a23b..2b7aa6e 100644
--- a/sys-libs/libcap/libcap-2.25.ebuild
+++ b/sys-libs/libcap/libcap-2.25.ebuild
@@ -4,7 +4,7 @@
 
 EAPI=5
 
-inherit eutils multilib multilib-minimal toolchain-funcs pam
+inherit eutils multilib multilib-minimal toolchain-funcs pam sep-usr
 
 DESCRIPTION="POSIX 1003.1e capabilities"
 HOMEPAGE="http://www.friedhoff.org/posixfilecaps.html;
@@ -16,7 +16,7 @@ SLOT="0"
 KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 
~sh ~sparc ~x86 ~amd64-linux ~arm-linux ~ia64-linux ~x86-linux"
 IUSE="pam static-libs"
 
-RDEPEND=">=sys-apps/attr-2.4.47-r1[${MULTILIB_USEDEP}]
+RDEPEND=">=sys-apps/attr-2.4.47-r1[${MULTILIB_USEDEP},sep-usr?]
pam? ( virtual/pam )"
 DEPEND="${RDEPEND}
sys-kernel/linux-headers"
-- 
2.7.4

[gentoo-dev] [PATCH 17/21] sys-libs/ncurses: switch to sep-usr eclass

[Mike Frysinger]

---
 sys-libs/ncurses/ncurses-5.9-r101.ebuild | 4 ++--
 sys-libs/ncurses/ncurses-5.9-r3.ebuild   | 4 ++--
 sys-libs/ncurses/ncurses-5.9-r4.ebuild   | 4 ++--
 sys-libs/ncurses/ncurses-5.9-r5.ebuild   | 4 ++--
 sys-libs/ncurses/ncurses-5.9-r99.ebuild  | 4 ++--
 sys-libs/ncurses/ncurses-6.0-r1.ebuild   | 4 ++--
 sys-libs/ncurses/ncurses-6.0.ebuild  | 4 ++--
 7 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/sys-libs/ncurses/ncurses-5.9-r101.ebuild 
b/sys-libs/ncurses/ncurses-5.9-r101.ebuild
index 541bb16..69de05f 100644
--- a/sys-libs/ncurses/ncurses-5.9-r101.ebuild
+++ b/sys-libs/ncurses/ncurses-5.9-r101.ebuild
@@ -6,7 +6,7 @@
 
 EAPI="5"
 
-inherit eutils toolchain-funcs multilib-minimal multiprocessing
+inherit eutils toolchain-funcs multilib-minimal multiprocessing sep-usr
 
 MY_PV=${PV:0:3}
 MY_P=${PN}-${MY_PV}
@@ -20,7 +20,7 @@ SLOT="5/5"
 KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 
~sh ~sparc ~x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd"
 IUSE="gpm tinfo unicode"
 
-DEPEND="gpm? ( sys-libs/gpm[${MULTILIB_USEDEP}] )"
+DEPEND="gpm? ( sys-libs/gpm[${MULTILIB_USEDEP},sep-usr?] )"
 # Block the ncurses-5 that installs the same lib. #557472
 RDEPEND="${DEPEND}
!https://www.gnu.org/software/ncurses/ 
http://dickey.his.com/ncurses/;
 LICENSE="metapackage"
 SLOT="5/5"
 KEYWORDS="alpha amd64 arm arm64 hppa ia64 ~m68k ~mips ppc ppc64 s390 ~sh sparc 
x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd"
-IUSE="ada +cxx gpm static-libs tinfo unicode"
+IUSE="ada +cxx gpm sep-usr static-libs tinfo unicode"
 
-DEPEND="sys-libs/ncurses:0/5[ada?,cxx?,gpm?,static-libs?,tinfo?,unicode?,${MULTILIB_USEDEP}]"
+DEPEND="sys-libs/ncurses:0/5[ada?,cxx?,gpm?,sep-usr?,static-libs?,tinfo?,unicode?,${MULTILIB_USEDEP}]"
 RDEPEND="${DEPEND}"
diff --git a/sys-libs/ncurses/ncurses-6.0-r1.ebuild 
b/sys-libs/ncurses/ncurses-6.0-r1.ebuild
index 029591b..ba51035 100644
--- a/sys-libs/ncurses/ncurses-6.0-r1.ebuild
+++ b/sys-libs/ncurses/ncurses-6.0-r1.ebuild
@@ -4,7 +4,7 @@
 
 EAPI="5"
 
-inherit eutils flag-o-matic toolchain-funcs multilib-minimal multiprocessing
+inherit eutils flag-o-matic toolchain-funcs multilib-minimal multiprocessing 
sep-usr
 
 MY_PV=${PV:0:3}
 PV_SNAP=${PV:4}
@@ -19,7 +19,7 @@ SLOT="0/6"
 KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 
~sh ~sparc ~x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd"
 IUSE="ada +cxx debug doc gpm minimal profile static-libs test threads tinfo 
trace unicode"
 
-DEPEND="gpm? ( sys-libs/gpm[${MULTILIB_USEDEP}] )"
+DEPEND="gpm? ( sys-libs/gpm[${MULTILIB_USEDEP},sep-usr?] )"
 #  berkdb? ( sys-libs/db )"
 # Block the older ncurses that installed all files w/SLOT=5. #557472
 RDEPEND="${DEPEND}
diff --git a/sys-libs/ncurses/ncurses-6.0.ebuild 
b/sys-libs/ncurses/ncurses-6.0.ebuild
index 3b85135..fd9c94d 100644
--- a/sys-libs/ncurses/ncurses-6.0.ebuild
+++ b/sys-libs/ncurses/ncurses-6.0.ebuild
@@ -15,7 +15,7 @@ HOMEPAGE="https://www.gnu.org/software/ncurses/ 
http://dickey.his.com/ncurses/;
 LICENSE="metapackage"
 SLOT="5/6"
 KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 
~sh ~sparc ~x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd"
-IUSE="ada +cxx gpm static-libs tinfo unicode"
+IUSE="ada +cxx gpm sep-usr static-libs tinfo unicode"
 
-DEPEND="sys-libs/ncurses:0/6[ada?,cxx?,gpm?,static-libs?,tinfo?,unicode?,${MULTILIB_USEDEP}]"
+DEPEND="sys-libs/ncurses:0/6[ada?,cxx?,gpm?,sep-usr?,static-libs?,tinfo?,unicode?,${MULTILIB_USEDEP}]"
 RDEPEND="${DEPEND}"
-- 
2.7.4

[gentoo-dev] [PATCH 19/21] dev-libs/libedit: switch to sep-usr eclass

[Mike Frysinger]

---
 dev-libs/libedit/libedit-20130712.3.1.ebuild | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/dev-libs/libedit/libedit-20130712.3.1.ebuild 
b/dev-libs/libedit/libedit-20130712.3.1.ebuild
index 50e38d6..4b1202f 100644
--- a/dev-libs/libedit/libedit-20130712.3.1.ebuild
+++ b/dev-libs/libedit/libedit-20130712.3.1.ebuild
@@ -4,7 +4,7 @@
 
 EAPI=5
 
-inherit eutils toolchain-funcs versionator base multilib-minimal
+inherit eutils toolchain-funcs versionator base multilib-minimal sep-usr
 
 MY_PV=$(get_major_version)-$(get_after_major_version)
 MY_P=${PN}-${MY_PV}
@@ -18,7 +18,7 @@ SLOT="0"
 KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc 
x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd ~x86-freebsd ~amd64-linux ~ia64-linux 
~x86-linux ~ppc-macos ~x64-macos ~x86-macos"
 IUSE="static-libs"
 
-DEPEND=">=sys-libs/ncurses-5.9-r3[static-libs?,${MULTILIB_USEDEP}]
+DEPEND=">=sys-libs/ncurses-5.9-r3[sep-usr?,static-libs?,${MULTILIB_USEDEP}]
!<=sys-freebsd/freebsd-lib-6.2_rc1"
 
 RDEPEND=${DEPEND}
-- 
2.7.4

[gentoo-dev] [PATCH 16/21] sys-libs/cracklib: switch to sep-usr eclass

[Mike Frysinger]

---
 sys-libs/cracklib/cracklib-2.9.1-r1.ebuild | 4 ++--
 sys-libs/cracklib/cracklib-2.9.4.ebuild| 4 ++--
 sys-libs/cracklib/cracklib-2.9.5.ebuild| 4 ++--
 sys-libs/cracklib/cracklib-2.9.6.ebuild| 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/sys-libs/cracklib/cracklib-2.9.1-r1.ebuild 
b/sys-libs/cracklib/cracklib-2.9.1-r1.ebuild
index 792bb37..c7e36a4 100644
--- a/sys-libs/cracklib/cracklib-2.9.1-r1.ebuild
+++ b/sys-libs/cracklib/cracklib-2.9.1-r1.ebuild
@@ -6,7 +6,7 @@ EAPI="4"
 PYTHON_COMPAT=( python2_7 )
 DISTUTILS_OPTIONAL=1
 
-inherit eutils distutils-r1 libtool multilib-minimal toolchain-funcs
+inherit eutils distutils-r1 libtool multilib-minimal sep-usr
 
 MY_P=${P/_}
 DESCRIPTION="Password Checking Library"
@@ -18,7 +18,7 @@ SLOT="0"
 KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc 
x86 ~x86-fbsd ~x86-interix ~amd64-linux ~ia64-linux ~x86-linux ~ppc-macos 
~x86-macos ~m68k-mint"
 IUSE="nls python static-libs test zlib"
 
-RDEPEND="zlib? ( >=sys-libs/zlib-1.2.8-r1[${MULTILIB_USEDEP}] )"
+RDEPEND="zlib? ( >=sys-libs/zlib-1.2.8-r1[sep-usr?,${MULTILIB_USEDEP}] )"
 DEPEND="${RDEPEND}
python? (
dev-python/setuptools[${PYTHON_USEDEP}]
diff --git a/sys-libs/cracklib/cracklib-2.9.4.ebuild 
b/sys-libs/cracklib/cracklib-2.9.4.ebuild
index a826ef9..f2fa977 100644
--- a/sys-libs/cracklib/cracklib-2.9.4.ebuild
+++ b/sys-libs/cracklib/cracklib-2.9.4.ebuild
@@ -6,7 +6,7 @@ EAPI="5"
 PYTHON_COMPAT=( python2_7 )
 DISTUTILS_OPTIONAL=1
 
-inherit eutils distutils-r1 libtool multilib-minimal toolchain-funcs
+inherit eutils distutils-r1 libtool multilib-minimal sep-usr
 
 MY_P=${P/_}
 DESCRIPTION="Password Checking Library"
@@ -18,7 +18,7 @@ SLOT="0"
 KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 
~sh ~sparc ~x86 ~x86-fbsd ~x86-interix ~amd64-linux ~ia64-linux ~x86-linux 
~ppc-macos ~x86-macos ~m68k-mint"
 IUSE="nls python static-libs test zlib"
 
-RDEPEND="zlib? ( >=sys-libs/zlib-1.2.8-r1[${MULTILIB_USEDEP}] )"
+RDEPEND="zlib? ( >=sys-libs/zlib-1.2.8-r1[sep-usr?,${MULTILIB_USEDEP}] )"
 DEPEND="${RDEPEND}
python? (
dev-python/setuptools[${PYTHON_USEDEP}]
diff --git a/sys-libs/cracklib/cracklib-2.9.5.ebuild 
b/sys-libs/cracklib/cracklib-2.9.5.ebuild
index a826ef9..f2fa977 100644
--- a/sys-libs/cracklib/cracklib-2.9.5.ebuild
+++ b/sys-libs/cracklib/cracklib-2.9.5.ebuild
@@ -6,7 +6,7 @@ EAPI="5"
 PYTHON_COMPAT=( python2_7 )
 DISTUTILS_OPTIONAL=1
 
-inherit eutils distutils-r1 libtool multilib-minimal toolchain-funcs
+inherit eutils distutils-r1 libtool multilib-minimal sep-usr
 
 MY_P=${P/_}
 DESCRIPTION="Password Checking Library"
@@ -18,7 +18,7 @@ SLOT="0"
 KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 
~sh ~sparc ~x86 ~x86-fbsd ~x86-interix ~amd64-linux ~ia64-linux ~x86-linux 
~ppc-macos ~x86-macos ~m68k-mint"
 IUSE="nls python static-libs test zlib"
 
-RDEPEND="zlib? ( >=sys-libs/zlib-1.2.8-r1[${MULTILIB_USEDEP}] )"
+RDEPEND="zlib? ( >=sys-libs/zlib-1.2.8-r1[sep-usr?,${MULTILIB_USEDEP}] )"
 DEPEND="${RDEPEND}
python? (
dev-python/setuptools[${PYTHON_USEDEP}]
diff --git a/sys-libs/cracklib/cracklib-2.9.6.ebuild 
b/sys-libs/cracklib/cracklib-2.9.6.ebuild
index dda19c0..fa3143a 100644
--- a/sys-libs/cracklib/cracklib-2.9.6.ebuild
+++ b/sys-libs/cracklib/cracklib-2.9.6.ebuild
@@ -6,7 +6,7 @@ EAPI="5"
 PYTHON_COMPAT=( python2_7 )
 DISTUTILS_OPTIONAL=1
 
-inherit eutils distutils-r1 libtool multilib-minimal toolchain-funcs
+inherit eutils distutils-r1 libtool multilib-minimal sep-usr
 
 MY_P=${P/_}
 DESCRIPTION="Password Checking Library"
@@ -18,7 +18,7 @@ SLOT="0"
 KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 
~sh ~sparc ~x86 ~x86-fbsd ~x86-interix ~amd64-linux ~ia64-linux ~x86-linux 
~ppc-macos ~x86-macos ~m68k-mint"
 IUSE="nls python static-libs test zlib"
 
-RDEPEND="zlib? ( >=sys-libs/zlib-1.2.8-r1[${MULTILIB_USEDEP}] )"
+RDEPEND="zlib? ( >=sys-libs/zlib-1.2.8-r1[sep-usr?,${MULTILIB_USEDEP}] )"
 DEPEND="${RDEPEND}
python? (
dev-python/setuptools[${PYTHON_USEDEP}]
-- 
2.7.4

[gentoo-dev] [PATCH 13/21] sys-apps/keyutils: switch to sep-usr eclass

[Mike Frysinger]

---
 sys-apps/keyutils/keyutils-1.5.9-r1.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sys-apps/keyutils/keyutils-1.5.9-r1.ebuild 
b/sys-apps/keyutils/keyutils-1.5.9-r1.ebuild
index 7b8ddbf..7a813c0 100644
--- a/sys-apps/keyutils/keyutils-1.5.9-r1.ebuild
+++ b/sys-apps/keyutils/keyutils-1.5.9-r1.ebuild
@@ -4,7 +4,7 @@
 
 EAPI="5"
 
-inherit multilib eutils toolchain-funcs linux-info multilib-minimal
+inherit multilib eutils toolchain-funcs linux-info multilib-minimal sep-usr
 
 DESCRIPTION="Linux Key Management Utilities"
 HOMEPAGE="https://people.redhat.com/dhowells/keyutils/;
-- 
2.7.4

[gentoo-dev] [PATCH 12/21] sys-libs/readline: switch to sep-usr eclass

[Mike Frysinger]

---
 sys-libs/readline/readline-6.2_p5-r1.ebuild | 2 +-
 sys-libs/readline/readline-6.3_p8-r1.ebuild | 2 +-
 sys-libs/readline/readline-6.3_p8-r2.ebuild | 2 +-
 sys-libs/readline/readline-7.0_rc1.ebuild   | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/sys-libs/readline/readline-6.2_p5-r1.ebuild 
b/sys-libs/readline/readline-6.2_p5-r1.ebuild
index 36ffdf4..153fbdd 100644
--- a/sys-libs/readline/readline-6.2_p5-r1.ebuild
+++ b/sys-libs/readline/readline-6.2_p5-r1.ebuild
@@ -4,7 +4,7 @@
 
 EAPI="4"
 
-inherit eutils multilib toolchain-funcs flag-o-matic multilib-minimal
+inherit eutils multilib toolchain-funcs flag-o-matic multilib-minimal sep-usr
 
 # Official patches
 # See ftp://ftp.cwru.edu/pub/bash/readline-6.2-patches/
diff --git a/sys-libs/readline/readline-6.3_p8-r1.ebuild 
b/sys-libs/readline/readline-6.3_p8-r1.ebuild
index 98588d9..a51cb78c 100644
--- a/sys-libs/readline/readline-6.3_p8-r1.ebuild
+++ b/sys-libs/readline/readline-6.3_p8-r1.ebuild
@@ -4,7 +4,7 @@
 
 EAPI=4
 
-inherit eutils multilib toolchain-funcs flag-o-matic multilib-minimal
+inherit eutils multilib toolchain-funcs flag-o-matic multilib-minimal sep-usr
 
 # Official patches
 # See ftp://ftp.cwru.edu/pub/bash/readline-6.3-patches/
diff --git a/sys-libs/readline/readline-6.3_p8-r2.ebuild 
b/sys-libs/readline/readline-6.3_p8-r2.ebuild
index ad21882..eca2b24 100644
--- a/sys-libs/readline/readline-6.3_p8-r2.ebuild
+++ b/sys-libs/readline/readline-6.3_p8-r2.ebuild
@@ -4,7 +4,7 @@
 
 EAPI=4
 
-inherit eutils multilib toolchain-funcs flag-o-matic multilib-minimal
+inherit eutils multilib toolchain-funcs flag-o-matic multilib-minimal sep-usr
 
 # Official patches
 # See ftp://ftp.cwru.edu/pub/bash/readline-6.3-patches/
diff --git a/sys-libs/readline/readline-7.0_rc1.ebuild 
b/sys-libs/readline/readline-7.0_rc1.ebuild
index da06224..ccbe927 100644
--- a/sys-libs/readline/readline-7.0_rc1.ebuild
+++ b/sys-libs/readline/readline-7.0_rc1.ebuild
@@ -4,7 +4,7 @@
 
 EAPI="5"
 
-inherit eutils multilib toolchain-funcs flag-o-matic multilib-minimal
+inherit eutils multilib toolchain-funcs flag-o-matic multilib-minimal sep-usr
 
 # Official patches
 # See ftp://ftp.cwru.edu/pub/bash/readline-6.3-patches/
-- 
2.7.4

[gentoo-dev] [PATCH 21/21] sys-apps/tcp-wrappers: switch to sep-usr eclass

[Mike Frysinger]

---
 sys-apps/tcp-wrappers/tcp-wrappers-7.6.22-r1.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sys-apps/tcp-wrappers/tcp-wrappers-7.6.22-r1.ebuild 
b/sys-apps/tcp-wrappers/tcp-wrappers-7.6.22-r1.ebuild
index 1496b09..4923e85 100644
--- a/sys-apps/tcp-wrappers/tcp-wrappers-7.6.22-r1.ebuild
+++ b/sys-apps/tcp-wrappers/tcp-wrappers-7.6.22-r1.ebuild
@@ -4,7 +4,7 @@
 
 EAPI="4"
 
-inherit eutils toolchain-funcs versionator flag-o-matic multilib-minimal
+inherit eutils toolchain-funcs versionator flag-o-matic multilib-minimal 
sep-usr
 
 MY_PV=$(get_version_component_range 1-2)
 DEB_PV=$(get_version_component_range 3)
-- 
2.7.4

[gentoo-dev] [PATCH 20/21] dev-libs/libpcre: switch to sep-usr eclass

[Mike Frysinger]

---
 dev-libs/libpcre/libpcre-8.38.ebuild | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/dev-libs/libpcre/libpcre-8.38.ebuild 
b/dev-libs/libpcre/libpcre-8.38.ebuild
index fcda8d2..f7c64aa 100644
--- a/dev-libs/libpcre/libpcre-8.38.ebuild
+++ b/dev-libs/libpcre/libpcre-8.38.ebuild
@@ -4,7 +4,7 @@
 
 EAPI="5"
 
-inherit eutils multilib libtool flag-o-matic toolchain-funcs multilib-minimal
+inherit eutils multilib libtool flag-o-matic toolchain-funcs multilib-minimal 
sep-usr
 
 DESCRIPTION="Perl-compatible regular expression library"
 HOMEPAGE="http://www.pcre.org/;
@@ -24,10 +24,10 @@ IUSE="bzip2 +cxx +jit libedit pcre16 pcre32 +readline 
+recursion-limit static-li
 REQUIRED_USE="readline? ( !libedit )
libedit? ( !readline )"
 
-RDEPEND="bzip2? ( app-arch/bzip2 )
-   zlib? ( sys-libs/zlib )
-   libedit? ( dev-libs/libedit )
-   readline? ( sys-libs/readline:0= )"
+RDEPEND="bzip2? ( app-arch/bzip2[sep-usr?] )
+   zlib? ( sys-libs/zlib[sep-usr?] )
+   libedit? ( dev-libs/libedit[sep-usr?] )
+   readline? ( sys-libs/readline:0=[sep-usr?] )"
 DEPEND="${RDEPEND}
virtual/pkgconfig"
 RDEPEND="${RDEPEND}
-- 
2.7.4

[gentoo-dev] [PATCH 18/21] dev-libs/libpwquality: switch to sep-usr eclass

[Mike Frysinger]

---
 dev-libs/libpwquality/libpwquality-1.3.0.ebuild | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/dev-libs/libpwquality/libpwquality-1.3.0.ebuild 
b/dev-libs/libpwquality/libpwquality-1.3.0.ebuild
index e2597b0..8082188 100644
--- a/dev-libs/libpwquality/libpwquality-1.3.0.ebuild
+++ b/dev-libs/libpwquality/libpwquality-1.3.0.ebuild
@@ -5,7 +5,7 @@
 EAPI="5"
 PYTHON_COMPAT=( python{2_7,3_3,3_4} )
 
-inherit eutils multilib pam python-r1 toolchain-funcs
+inherit eutils multilib pam python-r1 sep-usr
 
 DESCRIPTION="Library for password quality checking and generating random 
passwords"
 HOMEPAGE="https://fedorahosted.org/libpwquality/;
@@ -17,7 +17,7 @@ KEYWORDS="alpha amd64 arm arm64 hppa ia64 ~mips ppc ppc64 
s390 sh sparc x86"
 IUSE="pam python static-libs"
 
 RDEPEND="
-   >=sys-libs/cracklib-2.8:=
+   >=sys-libs/cracklib-2.8:=[sep-usr?]
pam? ( virtual/pam )
python? ( ${PYTHON_DEPS} )
 "
@@ -38,7 +38,6 @@ src_configure() {
configuring() {
local sitedir
econf \
-   --libdir="${EPREFIX}/$(get_libdir)" \
$(use_enable pam) \
--with-securedir="${EPREFIX}/$(getpam_mod_dir)" \
$(use_enable python python-bindings) \
@@ -58,12 +57,7 @@ src_test() {
 
 src_install() {
if_use_python_python_foreach_impl default
-   if use static-libs; then
-   # Do not install static libs in /lib
-   mkdir -p "${ED}usr/$(get_libdir)"
-   mv "${ED}$(get_libdir)/libpwquality.a" 
"${ED}/usr/$(get_libdir)/" || die
-   gen_usr_ldscript libpwquality.so
-   fi
+   gen_usr_ldscript -a pwquality
prune_libtool_files --modules
 }
 
-- 
2.7.4

[gentoo-dev] [PATCH 14/21] dev-libs/libaio: switch to sep-usr eclass

[Mike Frysinger]

---
 dev-libs/libaio/libaio-0.3.110.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dev-libs/libaio/libaio-0.3.110.ebuild 
b/dev-libs/libaio/libaio-0.3.110.ebuild
index 0605dbe..f625ba7 100644
--- a/dev-libs/libaio/libaio-0.3.110.ebuild
+++ b/dev-libs/libaio/libaio-0.3.110.ebuild
@@ -4,7 +4,7 @@
 
 EAPI=5
 
-inherit eutils multilib-minimal toolchain-funcs flag-o-matic
+inherit eutils multilib-minimal toolchain-funcs flag-o-matic sep-usr
 
 DESCRIPTION="Asynchronous input/output library that uses the kernels native 
interface"
 HOMEPAGE="https://git.fedorahosted.org/cgit/libaio.git/  
http://lse.sourceforge.net/io/aio.html;
-- 
2.7.4

[gentoo-dev] [PATCH 11/21] dev-libs/lzo: switch to sep-usr eclass

[Mike Frysinger]

---
 dev-libs/lzo/lzo-2.08-r1.ebuild | 2 +-
 dev-libs/lzo/lzo-2.09.ebuild| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/dev-libs/lzo/lzo-2.08-r1.ebuild b/dev-libs/lzo/lzo-2.08-r1.ebuild
index f3cff4b..e988b96 100644
--- a/dev-libs/lzo/lzo-2.08-r1.ebuild
+++ b/dev-libs/lzo/lzo-2.08-r1.ebuild
@@ -4,7 +4,7 @@
 
 EAPI=5
 
-inherit eutils multilib-minimal toolchain-funcs
+inherit eutils multilib-minimal sep-usr
 
 DESCRIPTION="An extremely fast compression and decompression library"
 HOMEPAGE="http://www.oberhumer.com/opensource/lzo/;
diff --git a/dev-libs/lzo/lzo-2.09.ebuild b/dev-libs/lzo/lzo-2.09.ebuild
index f3cff4b..e988b96 100644
--- a/dev-libs/lzo/lzo-2.09.ebuild
+++ b/dev-libs/lzo/lzo-2.09.ebuild
@@ -4,7 +4,7 @@
 
 EAPI=5
 
-inherit eutils multilib-minimal toolchain-funcs
+inherit eutils multilib-minimal sep-usr
 
 DESCRIPTION="An extremely fast compression and decompression library"
 HOMEPAGE="http://www.oberhumer.com/opensource/lzo/;
-- 
2.7.4

[gentoo-dev] [PATCH 10/21] sys-libs/pam: switch to sep-usr eclass

[Mike Frysinger]

---
 sys-libs/pam/pam-1.2.1-r1.ebuild | 4 ++--
 sys-libs/pam/pam-1.2.1.ebuild| 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/sys-libs/pam/pam-1.2.1-r1.ebuild b/sys-libs/pam/pam-1.2.1-r1.ebuild
index a3e541d..6cb59da 100644
--- a/sys-libs/pam/pam-1.2.1-r1.ebuild
+++ b/sys-libs/pam/pam-1.2.1-r1.ebuild
@@ -4,7 +4,7 @@
 
 EAPI=5
 
-inherit libtool multilib multilib-minimal eutils pam toolchain-funcs 
flag-o-matic db-use fcaps
+inherit libtool multilib multilib-minimal eutils pam toolchain-funcs 
flag-o-matic db-use sep-usr fcaps
 
 MY_PN="Linux-PAM"
 MY_P="${MY_PN}-${PV}"
@@ -138,7 +138,7 @@ multilib_src_install() {
sepermitlockdir="${EPREFIX}/run/sepermit"
 
local prefix
-   if multilib_is_native_abi; then
+   if use sep-usr; then
prefix=
gen_usr_ldscript -a pam pamc pam_misc
else
diff --git a/sys-libs/pam/pam-1.2.1.ebuild b/sys-libs/pam/pam-1.2.1.ebuild
index 8309dda..5241086 100644
--- a/sys-libs/pam/pam-1.2.1.ebuild
+++ b/sys-libs/pam/pam-1.2.1.ebuild
@@ -4,7 +4,7 @@
 
 EAPI=5
 
-inherit libtool multilib multilib-minimal eutils pam toolchain-funcs 
flag-o-matic db-use
+inherit libtool multilib multilib-minimal eutils pam toolchain-funcs 
flag-o-matic db-use sep-usr
 
 MY_PN="Linux-PAM"
 MY_P="${MY_PN}-${PV}"
@@ -136,7 +136,7 @@ multilib_src_install() {
sepermitlockdir="${EPREFIX}/run/sepermit"
 
local prefix
-   if multilib_is_native_abi; then
+   if use sep-usr; then
prefix=
gen_usr_ldscript -a pam pamc pam_misc
else
-- 
2.7.4

[gentoo-dev] [PATCH 09/21] sys-apps/attr: switch to sep-usr eclass

[Mike Frysinger]

---
 sys-apps/attr/attr-2.4.47-r2.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sys-apps/attr/attr-2.4.47-r2.ebuild 
b/sys-apps/attr/attr-2.4.47-r2.ebuild
index 11a6bda..06bac92 100644
--- a/sys-apps/attr/attr-2.4.47-r2.ebuild
+++ b/sys-apps/attr/attr-2.4.47-r2.ebuild
@@ -4,7 +4,7 @@
 
 EAPI="4"
 
-inherit eutils toolchain-funcs multilib-minimal
+inherit eutils multilib-minimal sep-usr
 
 DESCRIPTION="Extended attributes tools"
 HOMEPAGE="http://savannah.nongnu.org/projects/attr;
-- 
2.7.4

[gentoo-dev] [PATCH 07/21] app-arch/xz-utils: switch to sep-usr eclass

[Mike Frysinger]

---
 app-arch/xz-utils/xz-utils-5.2.2.ebuild | 2 +-
 app-arch/xz-utils/xz-utils-.ebuild  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/app-arch/xz-utils/xz-utils-5.2.2.ebuild 
b/app-arch/xz-utils/xz-utils-5.2.2.ebuild
index 34283d5..b5e54d2 100644
--- a/app-arch/xz-utils/xz-utils-5.2.2.ebuild
+++ b/app-arch/xz-utils/xz-utils-5.2.2.ebuild
@@ -7,7 +7,7 @@
 
 EAPI="4"
 
-inherit eutils multilib toolchain-funcs libtool multilib-minimal
+inherit eutils multilib libtool multilib-minimal sep-usr
 
 if [[ ${PV} == "" ]] ; then
EGIT_REPO_URI="http://git.tukaani.org/xz.git;
diff --git a/app-arch/xz-utils/xz-utils-.ebuild 
b/app-arch/xz-utils/xz-utils-.ebuild
index ac40bc4..784acf0 100644
--- a/app-arch/xz-utils/xz-utils-.ebuild
+++ b/app-arch/xz-utils/xz-utils-.ebuild
@@ -7,7 +7,7 @@
 
 EAPI="4"
 
-inherit eutils multilib toolchain-funcs libtool multilib-minimal
+inherit eutils multilib libtool multilib-minimal sep-usr
 
 if [[ ${PV} == "" ]] ; then
EGIT_REPO_URI="http://git.tukaani.org/xz.git;
-- 
2.7.4

[gentoo-dev] [PATCH 08/21] sys-apps/acl: switch to sep-usr eclass

[Mike Frysinger]

---
 sys-apps/acl/acl-2.2.52-r1.ebuild | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sys-apps/acl/acl-2.2.52-r1.ebuild 
b/sys-apps/acl/acl-2.2.52-r1.ebuild
index d1d2169..e645a73 100644
--- a/sys-apps/acl/acl-2.2.52-r1.ebuild
+++ b/sys-apps/acl/acl-2.2.52-r1.ebuild
@@ -4,7 +4,7 @@
 
 EAPI="4"
 
-inherit eutils toolchain-funcs multilib-minimal
+inherit eutils multilib-minimal sep-usr
 
 DESCRIPTION="access control list utilities, libraries and headers"
 HOMEPAGE="http://savannah.nongnu.org/projects/acl;
@@ -15,7 +15,7 @@ SLOT="0"
 KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc 
x86 ~amd64-linux ~arm-linux ~ia64-linux ~x86-linux"
 IUSE="nls static-libs"
 
-RDEPEND=">=sys-apps/attr-2.4.47-r1[${MULTILIB_USEDEP}]
+RDEPEND=">=sys-apps/attr-2.4.47-r1[${MULTILIB_USEDEP},sep-usr?]
abi_x86_32? (
!<=app-emulation/emul-linux-x86-baselibs-20140406-r2
!app-emulation/emul-linux-x86-baselibs[-abi_x86_32(-)]
-- 
2.7.4

[gentoo-dev] [PATCH 06/21] app-arch/bzip2: switch to sep-usr eclass

[Mike Frysinger]

---
 app-arch/bzip2/bzip2-1.0.6-r6.ebuild | 2 +-
 app-arch/bzip2/bzip2-1.0.6-r7.ebuild | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/app-arch/bzip2/bzip2-1.0.6-r6.ebuild 
b/app-arch/bzip2/bzip2-1.0.6-r6.ebuild
index d7b2cdf..95ce04d 100644
--- a/app-arch/bzip2/bzip2-1.0.6-r6.ebuild
+++ b/app-arch/bzip2/bzip2-1.0.6-r6.ebuild
@@ -7,7 +7,7 @@
 
 EAPI=4
 
-inherit eutils toolchain-funcs multilib multilib-minimal
+inherit eutils toolchain-funcs multilib multilib-minimal sep-usr
 
 DESCRIPTION="A high-quality data compressor used extensively by Gentoo Linux"
 HOMEPAGE="http://www.bzip.org/;
diff --git a/app-arch/bzip2/bzip2-1.0.6-r7.ebuild 
b/app-arch/bzip2/bzip2-1.0.6-r7.ebuild
index 60d0df3..4092978 100644
--- a/app-arch/bzip2/bzip2-1.0.6-r7.ebuild
+++ b/app-arch/bzip2/bzip2-1.0.6-r7.ebuild
@@ -7,7 +7,7 @@
 
 EAPI=4
 
-inherit eutils toolchain-funcs multilib multilib-minimal
+inherit eutils toolchain-funcs multilib multilib-minimal sep-usr
 
 DESCRIPTION="A high-quality data compressor used extensively by Gentoo Linux"
 HOMEPAGE="http://www.bzip.org/;
-- 
2.7.4

[gentoo-dev] [PATCH 05/21] sys-libs/gpm: switch to sep-usr eclass

[Mike Frysinger]

---
 sys-libs/gpm/gpm-1.20.7-r2.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sys-libs/gpm/gpm-1.20.7-r2.ebuild 
b/sys-libs/gpm/gpm-1.20.7-r2.ebuild
index ee9f5a7..a29bf7e 100644
--- a/sys-libs/gpm/gpm-1.20.7-r2.ebuild
+++ b/sys-libs/gpm/gpm-1.20.7-r2.ebuild
@@ -6,7 +6,7 @@
 
 EAPI="4"
 
-inherit eutils systemd toolchain-funcs autotools multilib-minimal
+inherit eutils systemd toolchain-funcs autotools multilib-minimal sep-usr
 
 DESCRIPTION="Console-based mouse driver"
 HOMEPAGE="http://www.nico.schottelius.org/software/gpm/;
-- 
2.7.4

[gentoo-dev] [PATCH 04/21] sys-libs/pwdb: switch to sep-usr eclass

[Mike Frysinger]

---
 sys-libs/pwdb/pwdb-0.62.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sys-libs/pwdb/pwdb-0.62.ebuild b/sys-libs/pwdb/pwdb-0.62.ebuild
index 920b19a..90f4a0e 100644
--- a/sys-libs/pwdb/pwdb-0.62.ebuild
+++ b/sys-libs/pwdb/pwdb-0.62.ebuild
@@ -4,7 +4,7 @@
 
 EAPI="4"
 
-inherit eutils toolchain-funcs flag-o-matic
+inherit eutils toolchain-funcs flag-o-matic sep-usr
 
 DESCRIPTION="Password database"
 HOMEPAGE="https://packages.gentoo.org/package/sys-libs/pwdb;
-- 
2.7.4

[gentoo-dev] [PATCH 03/21] sys-libs/zlib: switch to sep-usr eclass

[Mike Frysinger]

---
 sys-libs/zlib/zlib-1.2.8-r1.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sys-libs/zlib/zlib-1.2.8-r1.ebuild 
b/sys-libs/zlib/zlib-1.2.8-r1.ebuild
index 43a555a..23161b0 100644
--- a/sys-libs/zlib/zlib-1.2.8-r1.ebuild
+++ b/sys-libs/zlib/zlib-1.2.8-r1.ebuild
@@ -5,7 +5,7 @@
 EAPI=4
 AUTOTOOLS_AUTO_DEPEND="no"
 
-inherit autotools toolchain-funcs multilib multilib-minimal
+inherit autotools toolchain-funcs multilib multilib-minimal sep-usr
 
 DESCRIPTION="Standard (de)compression library"
 HOMEPAGE="http://www.zlib.net/;
-- 
2.7.4

[gentoo-dev] [PATCH 02/21] profiles: mask USE=sep-usr for most systems

[Mike Frysinger]

---
 profiles/base/use.mask  | 3 +++
 profiles/default/bsd/use.mask   | 4 
 profiles/default/linux/use.mask | 4 
 profiles/prefix/darwin/use.mask | 4 
 4 files changed, 15 insertions(+)

diff --git a/profiles/base/use.mask b/profiles/base/use.mask
index 3127dad..8ef3e3a 100644
--- a/profiles/base/use.mask
+++ b/profiles/base/use.mask
@@ -396,3 +396,6 @@ openrc-force
 # sys-libs/libapparmor
 apparmor
 
+# Mike Frysinger <vap...@gentoo.org> (30 Mar 2016)
+# Most systems do not support a sep-/usr partition.
+sep-usr
diff --git a/profiles/default/bsd/use.mask b/profiles/default/bsd/use.mask
index ba2cd7f..5776edd 100644
--- a/profiles/default/bsd/use.mask
+++ b/profiles/default/bsd/use.mask
@@ -77,3 +77,7 @@ sane_backends_qcam
 # Diego E. Pettenò <flamee...@gentoo.org> (19 oct 2010)
 # unmasking flags that only apply to FreeBSD
 -kqueue
+
+# Mike Frysinger <vap...@gentoo.org> (30 Mar 2016)
+# Allow people to opt-in to a sep-/usr partition.
+-sep-usr
diff --git a/profiles/default/linux/use.mask b/profiles/default/linux/use.mask
index 647b635..db46d3b 100644
--- a/profiles/default/linux/use.mask
+++ b/profiles/default/linux/use.mask
@@ -17,3 +17,7 @@ x264
 # Samuli Suominen <ssuomi...@gentoo.org> (19 Apr 2013)
 # Linux specific module loading/unloading support
 -kmod
+
+# Mike Frysinger <vap...@gentoo.org> (30 Mar 2016)
+# Allow people to opt-in to a sep-/usr partition.
+-sep-usr
diff --git a/profiles/prefix/darwin/use.mask b/profiles/prefix/darwin/use.mask
index 3b7c8f9..5473e88 100644
--- a/profiles/prefix/darwin/use.mask
+++ b/profiles/prefix/darwin/use.mask
@@ -43,3 +43,7 @@ v4l
 
 # introspection is far from working on OSX
 introspection
+
+# Mike Frysinger <vap...@gentoo.org> (30 Mar 2016)
+# Allow people to opt-in to a sep-/usr partition.
+-sep-usr
-- 
2.7.4

[gentoo-dev] [PATCH 01/21] sep-usr.eclass: new eclass to hold gen_usr_ldscript and related logic #417451

[Mike Frysinger]

This is mostly a copy of the func as it exists in the toolchain-funcs
eclass, but with some of the initial logic shifted to USE=sep-usr.
Once all ebuilds have switched over to this eclass, we can drop it
from the toolchain-funcs eclass.  In the meantime, make sure this is
inherited last.
---
 eclass/sep-usr.eclass | 152 ++
 profiles/use.desc |   1 +
 2 files changed, 153 insertions(+)
 create mode 100644 eclass/sep-usr.eclass

diff --git a/eclass/sep-usr.eclass b/eclass/sep-usr.eclass
new file mode 100644
index 000..c6791e1
--- /dev/null
+++ b/eclass/sep-usr.eclass
@@ -0,0 +1,152 @@
+# Copyright 1999-2016 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: sep-usr.eclass
+# @MAINTAINER:
+# Toolchain Ninjas 
+# @BLURB: functions to support a split /usr partition
+# @DESCRIPTION:
+# Some core packages might install extra files into / instead of /usr when
+# the expectation is that /usr is a separate mount point.  This eclass holds
+# various functions to simplify that process for ebuild writers.
+
+if [[ -z ${_SEP_USR_ECLASS} ]]; then
+_SEP_USR_ECLASS=1
+
+inherit multilib
+
+IUSE="sep-usr"
+
+# @FUNCTION: gen_usr_ldscript
+# @USAGE: [-a] 
+# @DESCRIPTION:
+# This function generate linker scripts in /usr/lib for dynamic
+# libs in /lib.  This is to fix linking problems when you have
+# the .so in /lib, and the .a in /usr/lib.  What happens is that
+# in some cases when linking dynamic, the .a in /usr/lib is used
+# instead of the .so in /lib due to gcc/libtool tweaking ld's
+# library search path.  This causes many builds to fail.
+# See bug #4411 for more info.
+#
+# Note that you should in general use the unversioned name of
+# the library (libfoo.so), as ldconfig should usually update it
+# correctly to point to the latest version of the library present.
+gen_usr_ldscript() {
+   local lib libdir=$(get_libdir) output_format="" auto=false 
suffix=$(get_libname)
+   [[ -z ${ED+set} ]] && local ED=${D%/}${EPREFIX}/
+
+   # This code only matters when it's been enabled. #417451
+   use sep-usr || return 0
+
+   # We only care about stuffing / for the native ABI. #479448
+   if [[ $(type -t multilib_is_native_abi) == "function" ]] ; then
+   multilib_is_native_abi || return 0
+   fi
+
+   # Just make sure it exists
+   dodir /usr/${libdir}
+
+   if [[ $1 == "-a" ]] ; then
+   auto=true
+   shift
+   dodir /${libdir}
+   fi
+
+   # OUTPUT_FORMAT gives hints to the linker as to what binary format
+   # is referenced ... makes multilib saner
+   local flags=( ${CFLAGS} ${LDFLAGS} -Wl,--verbose )
+   if $(tc-getLD) --version | grep -q 'GNU gold' ; then
+   # If they're using gold, manually invoke the old bfd. #487696
+   local d="${T}/bfd-linker"
+   mkdir -p "${d}"
+   ln -sf $(which ${CHOST}-ld.bfd) "${d}"/ld
+   flags+=( -B"${d}" )
+   fi
+   output_format=$($(tc-getCC) "${flags[@]}" 2>&1 | sed -n 
's/^OUTPUT_FORMAT("\([^"]*\)",.*/\1/p')
+   [[ -n ${output_format} ]] && output_format="OUTPUT_FORMAT ( 
${output_format} )"
+
+   for lib in "$@" ; do
+   local tlib
+   if ${auto} ; then
+   lib="lib${lib}${suffix}"
+   else
+   # Ensure /lib/${lib} exists to avoid dangling 
scripts/symlinks.
+   # This especially is for AIX where $(get_libname) can 
return ".a",
+   # so /lib/${lib} might be moved to /usr/lib/${lib} (by 
accident).
+   [[ -r ${ED}/${libdir}/${lib} ]] || continue
+   #TODO: better die here?
+   fi
+
+   case ${CTARGET:-${CHOST}} in
+   *-darwin*)
+   if ${auto} ; then
+   tlib=$(scanmacho -qF'%S#F' 
"${ED}"/usr/${libdir}/${lib})
+   else
+   tlib=$(scanmacho -qF'%S#F' 
"${ED}"/${libdir}/${lib})
+   fi
+   [[ -z ${tlib} ]] && die "unable to read install_name 
from ${lib}"
+   tlib=${tlib##*/}
+
+   if ${auto} ; then
+   mv 
"${ED}"/usr/${libdir}/${lib%${suffix}}.*${suffix#.} "${ED}"/${libdir}/ || die
+   # some install_names are funky: they encode a 
version
+   if [[ ${tlib} != ${lib%${suffix}}.*${suffix#.} 
]] ; then
+   mv 
"${ED}"/usr/${libdir}/${tlib%${suffix}}.*${suffix#.} "${ED}"/${libdir}/ || die
+   fi
+   rm -f "${ED}"/${libdir}/${lib}
+   fi
+
+   # Mach-O files have an id, which is like a soname, it 
tells how

[gentoo-dev] [PATCH 00/21] gen_usr_ldscript: migrate away from a sep-/usr by default

[Mike Frysinger]

To make forward progress on bug 417451, introduce a new sep-usr eclass
that will hold all logic related to having a separate /usr.  For now,
this is just the gen_usr_ldscript function and a new USE=sep-usr flag.

All ebuilds that call gen_usr_ldscript today will migrate to this and
will allow people to move away from installing things into /.  For the
systems that want to have a split-/usr partition, they can turn on this
USE flag across their system.

This also allows us to mask the flag on many targets where it doesn't
make sense (like most prefix setups) and where we don't want to support
it at all.

Mike Frysinger (21):
  sep-usr.eclass: new eclass to hold gen_usr_ldscript and related logic
#417451
  profiles: mask USE=sep-usr for most systems
  sys-libs/zlib: switch to sep-usr eclass
  sys-libs/pwdb: switch to sep-usr eclass
  sys-libs/gpm: switch to sep-usr eclass
  app-arch/bzip2: switch to sep-usr eclass
  app-arch/xz-utils: switch to sep-usr eclass
  sys-apps/acl: switch to sep-usr eclass
  sys-apps/attr: switch to sep-usr eclass
  sys-libs/pam: switch to sep-usr eclass
  dev-libs/lzo: switch to sep-usr eclass
  sys-libs/readline: switch to sep-usr eclass
  sys-apps/keyutils: switch to sep-usr eclass
  dev-libs/libaio: switch to sep-usr eclass
  sys-libs/libcap: switch to sep-usr eclass
  sys-libs/cracklib: switch to sep-usr eclass
  sys-libs/ncurses: switch to sep-usr eclass
  dev-libs/libpwquality: switch to sep-usr eclass
  dev-libs/libedit: switch to sep-usr eclass
  dev-libs/libpcre: switch to sep-usr eclass
  sys-apps/tcp-wrappers: switch to sep-usr eclass

 app-arch/bzip2/bzip2-1.0.6-r6.ebuild   |   2 +-
 app-arch/bzip2/bzip2-1.0.6-r7.ebuild   |   2 +-
 app-arch/xz-utils/xz-utils-5.2.2.ebuild|   2 +-
 app-arch/xz-utils/xz-utils-.ebuild |   2 +-
 dev-libs/libaio/libaio-0.3.110.ebuild  |   2 +-
 dev-libs/libedit/libedit-20130712.3.1.ebuild   |   4 +-
 dev-libs/libpcre/libpcre-8.38.ebuild   |  10 +-
 dev-libs/libpwquality/libpwquality-1.3.0.ebuild|  12 +-
 dev-libs/lzo/lzo-2.08-r1.ebuild|   2 +-
 dev-libs/lzo/lzo-2.09.ebuild   |   2 +-
 eclass/sep-usr.eclass  | 152 +
 profiles/base/use.mask |   3 +
 profiles/default/bsd/use.mask  |   4 +
 profiles/default/linux/use.mask|   4 +
 profiles/prefix/darwin/use.mask|   4 +
 profiles/use.desc  |   1 +
 sys-apps/acl/acl-2.2.52-r1.ebuild  |   4 +-
 sys-apps/attr/attr-2.4.47-r2.ebuild|   2 +-
 sys-apps/keyutils/keyutils-1.5.9-r1.ebuild |   2 +-
 .../tcp-wrappers/tcp-wrappers-7.6.22-r1.ebuild |   2 +-
 sys-libs/cracklib/cracklib-2.9.1-r1.ebuild |   4 +-
 sys-libs/cracklib/cracklib-2.9.4.ebuild|   4 +-
 sys-libs/cracklib/cracklib-2.9.5.ebuild|   4 +-
 sys-libs/cracklib/cracklib-2.9.6.ebuild|   4 +-
 sys-libs/gpm/gpm-1.20.7-r2.ebuild  |   2 +-
 sys-libs/libcap/libcap-2.24-r2.ebuild  |   4 +-
 sys-libs/libcap/libcap-2.25.ebuild |   4 +-
 sys-libs/ncurses/ncurses-5.9-r101.ebuild   |   4 +-
 sys-libs/ncurses/ncurses-5.9-r3.ebuild |   4 +-
 sys-libs/ncurses/ncurses-5.9-r4.ebuild |   4 +-
 sys-libs/ncurses/ncurses-5.9-r5.ebuild |   4 +-
 sys-libs/ncurses/ncurses-5.9-r99.ebuild|   4 +-
 sys-libs/ncurses/ncurses-6.0-r1.ebuild |   4 +-
 sys-libs/ncurses/ncurses-6.0.ebuild|   4 +-
 sys-libs/pam/pam-1.2.1-r1.ebuild   |   4 +-
 sys-libs/pam/pam-1.2.1.ebuild  |   4 +-
 sys-libs/pwdb/pwdb-0.62.ebuild |   2 +-
 sys-libs/readline/readline-6.2_p5-r1.ebuild|   2 +-
 sys-libs/readline/readline-6.3_p8-r1.ebuild|   2 +-
 sys-libs/readline/readline-6.3_p8-r2.ebuild|   2 +-
 sys-libs/readline/readline-7.0_rc1.ebuild  |   2 +-
 sys-libs/zlib/zlib-1.2.8-r1.ebuild |   2 +-
 42 files changed, 227 insertions(+), 65 deletions(-)
 create mode 100644 eclass/sep-usr.eclass

-- 
2.7.4

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

On 15 Feb 2016 13:13, Francesco Riosa wrote:
> Also, why, why people using systemd ARE interested in this thread?
> You should not be interested at all.

in case you're directing at me, i do not use systemd anywhere
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

On 15 Feb 2016 02:31, M. J. Everitt wrote:
> I think people are confusing the fact that there IS no separate 'udev'

i'm fully aware of this fact and have been since it happened.
i don't think it changes my point.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

On 14 Feb 2016 15:56, Anthony G. Basile wrote:
> On 2/14/16 3:47 PM, Mike Frysinger wrote:
> > On 14 Feb 2016 15:42, Anthony G. Basile wrote:
> >> On 2/14/16 3:23 PM, Mike Frysinger wrote:
> >>> eudev: no one of any relevance outside of Gentoo runs it.
> >> 
> >> that's not true, nor is it the central criticism, imo.
> > 
> > can you list the projects that utilize eudev ?  the repo doesn't
> > that i can see.  it is the central criticism imo when correct
> > interaction with other projects is key.  people rely on rules being
> > parsed & run correctly, as well as information provided by udev
> > matching what they are running/testing everyday.
> 
> until patrick brought up the list of distros, i was only aware of
> alpine which is a musl based distro.  then puppy and slack came
> forward.  they build their entire system using eudev as the libudev
> provider.  if there were issues, they would bring forward bug reports
> like any other project.
> 
> so when you say "people rely on rules being parsed ..." i don't know
> why those user bases are dismissed.

i'm not dismissing them per-se.  i'm being practical here: i think you
can agree that the combined developer base of alpine/puppy/slack(ware?)
is significantly smaller as compared to the distros using udev.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

On 14 Feb 2016 11:41, Brian Dolbec wrote:
> On Sun, 14 Feb 2016 11:00:30 -0500 Rich Freeman wrote:
> > On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer wrote:
> > > If, for any reason, eudev should be abandoned - we can just change
> > > the virtual back. One-line change.  
> > 
> > Which is precisely the corresponding argument for not switching the
> > default to eudev in the first place.
> 
> OH, my, this is looking more like you are being paid by systemd peeps...

honestly ?  cut the crap man.

> You are just refusing to acknowledge these simple facts.
> 
> systemd.:  irrelevant to this decision
> 
> standalone systemd-udev.:  Vehemently unsupported, support for its
>capability to exist is planned to be punted
>in the future.
> 
> eudev...:  fully functional, actively developed,
>and fully supported, mature project, been
>around for years.

udev: it's the default in every major distro that everyone tests and
develops against.

eudev: no one of any relevance outside of Gentoo runs it.

> Oh and here is one final piece that should blow your reason away
> 
> https://github.com/gentoo/eudev   <== NOTICE that it's upstream is
> within our gentoo domain.

irrelevant.  any Gentoo dev can create any repo in that namespace even
when they shouldn't.  the fact that eudev is in there does *not* mean
the whole Gentoo project has signed on to it, or that it's some sort
of "banner" project.  it means at least one Gentoo dev decided to do X
and our project system doesn't require project consensus before X can
proceed.  do not conflate these.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

On 14 Feb 2016 22:31, Alon Bar-Lev wrote:
> On 14 February 2016 at 22:23, Mike Frysinger wrote:
> > udev: it's the default in every major distro that everyone tests and
> > develops against.
> >
> > eudev: no one of any relevance outside of Gentoo runs it.
> 
> I honestly don't understand this argument that pops over and over.
> 
> No "major distro" using udev without systemd, so OpenRC people are
> already using udev in unsupported setup.
> 
> Better to use a tool that is tested and supported in this setup.

the bring up of the daemon itself is not nearly as important as the
runtime interaction of people using libudev or rules being executed.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

On 14 Feb 2016 21:31, Patrick Lauer wrote:
> On 02/14/2016 09:23 PM, Mike Frysinger wrote:
> > On 14 Feb 2016 11:41, Brian Dolbec wrote:
> >> On Sun, 14 Feb 2016 11:00:30 -0500 Rich Freeman wrote:
> >>> On Sun, Feb 14, 2016 at 10:14 AM, Patrick Lauer wrote:
> >>>> If, for any reason, eudev should be abandoned - we can just change
> >>>> the virtual back. One-line change.  
> >>> Which is precisely the corresponding argument for not switching the
> >>> default to eudev in the first place.
> >> OH, my, this is looking more like you are being paid by systemd peeps...
> > honestly ?  cut the crap man.
> >
> >> You are just refusing to acknowledge these simple facts.
> >>
> >> systemd.:  irrelevant to this decision
> >>
> >> standalone systemd-udev.:  Vehemently unsupported, support for its
> >>capability to exist is planned to be punted
> >>in the future.
> >>
> >> eudev...:  fully functional, actively developed,
> >>and fully supported, mature project, been
> >>around for years.
> > udev: it's the default in every major distro that everyone tests and
> > develops against.
> Not the standalone config we're using, so if you remove all
> systemd-using distros which are irrelevant to this discussion you end up
> with gentoo, and ~15 distros that use eudev. And of course other
> irrelevant weirdos that use mdev, vdev etc.
> >
> > eudev: no one of any relevance outside of Gentoo runs it.
> No one runs udev either. So that's a non-argument
> 
> 
> So given the context of this discussion, and your ignorant contribution
> ... maybe you should cut the crap, man. Being a bit more polite wouldn't
> be wrong either.

yes, your e-mails in this thread are a shining example of how to
collobarate and make cogent arguments.  attacking people directly
is definitely how you "win".  it's too bad i haven't actually done
any of what you're attempting to slander me with here.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

On 14 Feb 2016 15:42, Anthony G. Basile wrote:
> On 2/14/16 3:23 PM, Mike Frysinger wrote:
> > eudev: no one of any relevance outside of Gentoo runs it.
> 
> that's not true, nor is it the central criticism, imo.

can you list the projects that utilize eudev ?  the repo doesn't that
i can see.  it is the central criticism imo when correct interaction
with other projects is key.  people rely on rules being parsed & run
correctly, as well as information provided by udev matching what they
are running/testing everyday.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

On 14 Feb 2016 15:47, Anthony G. Basile wrote:
> On 2/14/16 3:34 PM, Mike Frysinger wrote:
> > the bring up of the daemon itself is not nearly as important as the
> > runtime interaction of people using libudev or rules being executed.
> 
> correct and i've been careful with libudev.
> 
> anyhow, can we divert this away from udev/eudev.  mike what do you
> recommend as the future of openrc once systemd-udev can no longer be
> extracted.

if/when systemd-udev can't be extract anymore, then sys-fs/udev is dead,
and this whole thread is fairly moot.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] abusive behaviour / communications from a user

[Mike Frysinger]

On 02 Feb 2016 11:14, Ian Delaney wrote:
> Members of comrel

this is the gentoo-dev list.  no idea why you're posting it here.
if you want to rope in comrel, then do so on the bug, or file a
new bug for them, or e-mail them directly.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Mike Frysinger]

On 08 Feb 2016 13:46, Michał Górny wrote:
> I'm strongly against this, because:

agreed.  i also don't see any reasons in Patrick's e-mail to suggest
the current default is inadequate.  "i don't like upstream" isn't
relevant.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [Fwd: [gentoo-automated-testing] BROKEN: repository became broken!]

[Mike Frysinger]

On 03 Feb 2016 22:35, Andreas K. Huettel wrote:
> Am Dienstag, 2. Februar 2016, 02:33:30 schrieb Mike Frysinger:
> > > I took the liberty of doing (2) and reverted the commit. Not sure why
> > > this needs so much discussion; after all a broken tree is always
> > > suboptimal.
> > 
> > unless things are on fire (which i don't think this was), i don't
> > generally clamor for 0-day fixes.  if we can find a better fix in
> > a day or so, then i'm happy for that.  i dislike repos with history
> > that is just a constant stream of land, revert, land, revert, land.
> > 
> > not that i'm saying your revert was wrong ... just airing my
> > general personal preferences.
> 
> You're right of course... but there's one thing we have to keep in mind.
> 
> We're not running a project were releases are made from the vcs. The vcs *is* 
> the release... and whatever is out there gets pushed to users.
> 
> This is why my personal preference is more to revert if I'm not sure that the 
> fix will happen soon.

which is why you weigh the impact on users.  how many people are actually
affected and for how long ?  in this case, fairly sure no actual user saw
the failure on their system.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: Changing order of default virtual/udev provider

[Mike Frysinger]

On 09 Feb 2016 22:39, Duncan wrote:
> Mike Frysinger posted on Tue, 09 Feb 2016 14:26:52 -0500 as excerpted:
> > On 08 Feb 2016 13:46, Michał Górny wrote:
> >> I'm strongly against this, because:
> > 
> > agreed.  i also don't see any reasons in Patrick's e-mail to suggest the
> > current default is inadequate.  "i don't like upstream" isn't relevant.
> 
> I'd agree, except that the way we're running udev is strongly discouraged 
> and generally not supported by upstream, with a statement that it /will/ 
> break in the future, it's simply a matter of time. 

start a thread then when that actually happens
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [Fwd: [gentoo-automated-testing] BROKEN: repository became broken!]

[Mike Frysinger]

On 01 Feb 2016 19:55, Patrice Clement wrote:
> > New issues:
> > https://qa-reports.gentoo.org/output/gentoo-ci/780f65b/output.html#dev-libs/efl
>
> This commit is breaking the tree:
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=97a6aec
> 
> I did try to work around the issue you've introduced when but the 
> enlightenment
> eclasses are a bit of mystery to me and I eventually gave up.
> 
> Could you revert this commit and fix this issue?

the issue is that efl-1.15.2 is marked stable for alpha/ia64/sparc, and
it depends on app-i18n/ibus, but commit 97a6aec deleted the only ibus
ebuild that was marked stable for those arches.

it can be fixed in a few ways (i'm listing in order of preference):
(1) mark a newer ibus stable
(2) revert that commit to re-add the old stable ebuilds
(3) add USE=ibus to package.use.stable.mask for these arches
(4) degrade all packages for these arches to unstable
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [Fwd: [gentoo-automated-testing] BROKEN: repository became broken!]

[Mike Frysinger]

On 01 Feb 2016 22:16, Andreas K. Huettel wrote:
> Am Montag, 1. Februar 2016, 21:30:41 schrieb Mike Frysinger:
> > On 01 Feb 2016 19:55, Patrice Clement wrote:
> > > > New issues:
> > > > https://qa-reports.gentoo.org/output/gentoo-ci/780f65b/output.html#dev-libs/efl
> > > 
> > > This commit is breaking the tree:
> > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=97a6aec
> > > 
> > > I did try to work around the issue you've introduced when but the
> > > enlightenment eclasses are a bit of mystery to me and I eventually gave
> > > up.
> > > 
> > > Could you revert this commit and fix this issue?
> > 
> > the issue is that efl-1.15.2 is marked stable for alpha/ia64/sparc, and
> > it depends on app-i18n/ibus, but commit 97a6aec deleted the only ibus
> > ebuild that was marked stable for those arches.
> > 
> > it can be fixed in a few ways (i'm listing in order of preference):
> > (1) mark a newer ibus stable
> > (2) revert that commit to re-add the old stable ebuilds
> > (3) add USE=ibus to package.use.stable.mask for these arches
> > (4) degrade all packages for these arches to unstable
> 
> I took the liberty of doing (2) and reverted the commit. Not sure why this 
> needs so much discussion; after all a broken tree is always suboptimal.

unless things are on fire (which i don't think this was), i don't
generally clamor for 0-day fixes.  if we can find a better fix in
a day or so, then i'm happy for that.  i dislike repos with history
that is just a constant stream of land, revert, land, revert, land.

not that i'm saying your revert was wrong ... just airing my
general personal preferences.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [PATCH] eutils.eclass: make_desktop_entry, remove unnecesssary extglob use

[Mike Frysinger]

On 29 Jan 2016 09:24, Michał Górny wrote:
> Remove an unnecessary extglob setting where a simpler ${foo%.*} is going
> to suffice, considering that the stripping is done conditionally after
> checking that one of the supported suffixes is used.

looks obvious enough
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings

[Mike Frysinger]

On 22 Jan 2016 12:04, Alexis Ballier wrote:
> On Thu, 21 Jan 2016 18:45:20 +0100 Michał Górny wrote:
> > If I see a package that clearly doesn't build or otherwise simply
> > doesn't work, could not have worked for past 3 years, are you forcing
> > me to waste a time reporting a bug to no maintainer who could fix it?
> 
> sure, don't waste your time and just delete it so that nobody can track
> why it was removed or even attempt to fix it.
> 
> > Because to me, the lack of any open bugs is a clear evidence that
> > the package is not only unmaintained, but also unused.
> 
> lack of open bug means there is no known bug; anything else is pure
> supposition

this.  if anything, it sounds like i need to keep open a trivial bug
for a package to keep people from wrongly proactively tree cleaning.

the # of users of a package is irrelevant.  if there are (real i.e. not
"typo in message" bugs) open, then that's a diff story.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: Herd likely up for grabs: kernel-misc

[Mike Frysinger]

On 20 Jan 2016 19:48, Duncan wrote:
> Mike Frysinger posted on Wed, 20 Jan 2016 13:40:04 -0500 as excerpted:
> > if base-system@ isn't going to maintain it, we'll punt it from the herd
> 
> Umm, you mean project, right?  Because the whole discussion here is part 
> of getting rid of herds.  =:^)

a distinction without a difference
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Herd up for grabs: xbox

[Mike Frysinger]

On 18 Jan 2016 10:38, Alexis Ballier wrote:
> On Sun, 17 Jan 2016 17:47:54 +0100 Michał Górny wrote:
> > media-tv/kodi: 
> > media-tv/xbmc: 
> 
> you can add video herd for these two if vapier is ok with that i think

sounds fine
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Herd likely up for grabs: kernel-misc

[Mike Frysinger]

On 18 Jan 2016 00:57, Joshua Kinard wrote:
> On 01/17/2016 14:57, Michał Górny wrote:
> > Hello, everyone.
> > 
> > The current maintainers of kernel-misc herd so far haven't replied to
> > our queries. If we don't get any reply in a week, we will be disbanding
> > it and looking for new maintainers for its packages.
> > 
> > Is anyone interested in keeping the herd as a whole and maintaining all
> > of its packages? If nobody replies till 2016-01-24, the herd will be
> > automatically disbanded and I will be sending a complete list of
> > packages needing maintainers.
> > 
> > Packages currently in herd along with their other maintainers:
> > 
> 
> [snip]
> 
> > sys-apps/kexec-tools : 
> 
> Better suited for base-system, maybe?
> 
> [snip]
> 
> > sys-fs/jfsutils  : 
> 
> Definitely base-system, as xfsprogs is already maintained by them.

sounds fine for both.  generally fs tools probably should live under
base-system for consistency.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Herd likely up for grabs: net-fs

[Mike Frysinger]

On 17 Jan 2016 21:03, Michał Górny wrote:
> net-fs/autofs: dlan@
> net-fs/curlftpfs : slyfox@
> net-fs/davfs2: proxy-maintainers, gokt...@binghamton.edu
> net-fs/libnfs: 
> net-fs/ncpfs : 
> net-fs/netatalk  : 
> net-fs/nfs4-acl-tools: 
> net-fs/nfstest   : prometheanfire@
> net-fs/nfs-utils : 
> net-fs/openafs   : NP-Hardass@, bircoph@
> net-fs/openafs-kernel: NP-Hardass@, bircoph@
> net-fs/openafs-legacy: 
> net-libs/libgssglue  : 
> net-libs/libnfsidmap : 
> net-libs/librpcsecgss: 
> net-libs/libtirpc: 
> net-libs/rpc2: 
> net-nds/portmap  : base-system
> net-nds/rpcbind  : 
> sys-libs/lwp : 
> sys-libs/rvm : 

https://bugs.gentoo.org/569422#c3

nfs/rpc projects will move to base-system@.  the rest are up for grabs.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Herd up for grabs: net-dialup

[Mike Frysinger]

On 17 Jan 2016 21:57, Lars Wendler wrote:
> I am going to take the following packages:
> 
> net-dialup/mingetty
> net-dialup/ppp
> net-dialup/rp-pppoe
> 
> I think that I might not be the perfect maintainer for these packages
> (especially for ppp) so if anyone else wants to maintain these, feel
> free to add yourself as well.

how about moving those to base-system@ ?

for the low level serial ones, we can move them to embedded since they
get way more use there nowadays than w/dialup modems.
app-misc/ckermit
net-dialup/lrzsz
net-dialup/minicom
net-dialup/picocom
net-dialup/xc
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Herd likely up for grabs: kernel-misc

[Mike Frysinger]

On 20 Jan 2016 12:39, Rich Freeman wrote:
> On Wed, Jan 20, 2016 at 12:34 PM, Mike Frysinger <vap...@gentoo.org> wrote:
> > On 18 Jan 2016 00:57, Joshua Kinard wrote:
> >> On 01/17/2016 14:57, Michał Górny wrote:
> >> > sys-apps/kexec-tools :
> >>
> >> Better suited for base-system, maybe?
> >>
> >> > sys-fs/jfsutils  :
> >>
> >> Definitely base-system, as xfsprogs is already maintained by them.
> >
> > sounds fine for both.  generally fs tools probably should live under
> > base-system for consistency.
> 
> Nothing wrong with consistency, but I'd prefer a package to be placed
> under the base-system project because the base-system project members
> intend to maintain it.  I don't want to see packages placed into
> projects simply because they're similar to other packages in those
> projects if it means they'll just be neglected.
> 
> I have no idea which is the case here.  If the base-system maintainers
> want to maintain these two packages, have at it!  If not, leave it as
> maintainer-needed.

if base-system@ isn't going to maintain it, we'll punt it from the herd
-mike


signature.asc
Description: Digital signature

Re: [gentoo-portage-dev] [PATCH] repoman: filter out duplicate dependencies in error messages

[Mike Frysinger]

On 04 Jan 2016 19:17, Brian Dolbec wrote:
> I immediately want to say REJECT!, REJECT!, REJECT!,...
> ...
> I would much prefer you re-base your patch on the rewrite code.

reject != delay ... i don't mind waiting and rebasing
-mike


signature.asc
Description: Digital signature

[gentoo-portage-dev] [PATCH] repoman: filter out duplicate dependencies in error messages

[Mike Frysinger]

Some packages list the same atom multiple times (e.g. behind diff USE
flags).  If one of them throws an error, we end up listing it more than
once, and the output can get verbose/useless.
---
 pym/repoman/scanner.py | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/pym/repoman/scanner.py b/pym/repoman/scanner.py
index d1c10d7..94ada90 100644
--- a/pym/repoman/scanner.py
+++ b/pym/repoman/scanner.py
@@ -704,13 +704,22 @@ class Scanner(object):
 
# we have some 
unsolvable deps
# remove ! 
deps, which always show up as unsatisfiable
-   atoms = [
+   all_atoms = [

str(atom.unevaluated_atom)
for 
atom in atoms if not atom.blocker]
 
# if we emptied 
out our list, continue:
-   if not atoms:
+   if not 
all_atoms:
continue
+
+   # Filter out 
duplicates.  We do this by hand (rather
+   # than use a 
set) so the order is stable and better
+   # matches the 
order that's in the ebuild itself.
+   atoms = []
+   for atom in 
all_atoms:
+   if atom 
not in atoms:
+   
atoms.append(atom)
+
if 
self.options.output_style in ['column']:

self.qatracker.add_error(mykey,

"%s: %s: %s(%s) %s"
-- 
2.6.2

Re: [gentoo-dev] Use GLEP27!

[Mike Frysinger]

On 17 Dec 2015 11:57, Ulrich Mueller wrote:
> >>>>> On Tue, 15 Dec 2015, Mike Frysinger wrote:
> > On 15 Dec 2015 20:23, Anthony G. Basile wrote:
> >> > short/mid term, i was thinking of writing a new package that
> >> > holds the db and tools to query/manage it. user.eclass would
> >> > DEPEND on it and ask it for details, perhaps even doing the
> >> > actual fs updates (the bash code here is not pretty wrt locks and
> >> > python would be much nicer). that tool could even search
> >> > additional site paths (like /usr/local) to locate overrides.
> >> 
> >> how do we get our own uid/gid's in there for our packages? just
> >> open a bug against the new package?
> 
> > i would open the git repo to all devs and just let anyone push
> > directly and roll releases. maybe just push a tag and that's what
> > the ebuild would hit. no need to be gate keepers here since we don't
> > today w/ebuilds and calls to enew{user,group}.
> 
> So if I want to add a new user or group, I would have to commit it to
> the repo of that package, then roll a new release, create an ebuild
> for that release, add that version to DEPEND of my own package's
> ebuild, and only then my ebuild could refer to the new user? And
> eventually, I'd have to take care of stabilising things, too? That
> looks like a cumbersome procedure, even if it is only intended as a
> stopgap solution until we can move things to a profile.

yes, that's what you'd have to do.  considering packages themselves have
to go through stabilization, that particular aspect isn't a big deal.  or
we just auto-stable it.

> Couldn't we add the user/group db to a subdir of the eclass dir
> instead, so that user.eclass could access it there?

people get whiny when we leverage eclass/ for storage.  but we do it
already, so it makes no difference to me.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: rfc: openrc c api (librc) usage

[Mike Frysinger]

On 16 Dec 2015 06:44, Duncan wrote:
> Mike Frysinger posted on Tue, 15 Dec 2015 00:00:51 -0500 as excerpted:
> > On 10 Dec 2015 10:32, William Hubbs wrote:
> >> I want to start a discussion about the usage of OpenRC's C api as
> >> defined in rc.h.
> > 
> > very few projects ever picked up the API/libraries.  probably for the
> > best.
> > 
> >> I have no idea which projectss out there are using it, or which
> >> functions they are using.
> > 
> > look at the RDEPEND in ebuilds.  if a package uses the libs, it should
> > be listed there.
> 
> Even with openrc still in @system?  Doesn't look like that bug has been 
> fixed yet.[1]

if you link against openrc, you need to RDEPEND on it
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: converting copyright/license information in OpenRC

[Mike Frysinger]

On 15 Dec 2015 09:31, William Hubbs wrote:
> On Tue, Dec 15, 2015 at 12:05:07AM -0500, Mike Frysinger wrote:
> > On 11 Dec 2015 14:16, Patrick McLean wrote:
> > > On Fri, 11 Dec 2015 15:37:48 -0600 William Hubbs wrote:
> > > > On Fri, Dec 11, 2015 at 09:04:47PM +0100, Ulrich Mueller wrote:
> > > > > >>>>> On Fri, 11 Dec 2015, William Hubbs wrote:  
> > > > >   
> > > > Well, the OpenRC project is currently inconsistent about this, so the
> > > > intention is to make it consistent.
> > > > 
> > > >  The .c/.h files have file-scope licenses, but that isn't true for
> > > >  everything in the project.
> > > > 
> > > > I am willing to make the effort to do this, I was just wondering if
> > > > there are any legal pitfalls I need to worry about.
> > > > 
> > > > My theory is I can probably use git to find out who all of the authors
> > > > are, and generate an Authors list from that information and from
> > > > looking at copyright notices.
> > > 
> > > One concern about this is the possibility of copied code. If OpenRC
> > > ever copied code from other BSD licensed projects, then dropping the
> > > notice from the top of the file would be a violation of the upstream
> > > license.
> > 
> > OpenRC isn't purely Gentoo copyright, so it's already a violation.
> > the majority of entries belong to Roy.
> 
> I have no idea what you mean by "it's already a violation", and I'm not
> sure what Gentoo Copyright has to do with it.

your description sounds like you want to run:
  s/Copyright .*/Copyright OpenRC Authors/

i'm saying you can't do that

> Altering Copyright statements to try to claim Gentoo copyright would
> definitely be a violation, but that's not what I'm wanting to do.

adding multiple entries isn't a problem and in fact could/should be done
in most openrc files at this time
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: converting copyright/license information in OpenRC

[Mike Frysinger]

On 15 Dec 2015 13:37, William Hubbs wrote:
> On Tue, Dec 15, 2015 at 02:24:22PM -0500, Mike Frysinger wrote:
> > your description sounds like you want to run:
> >   s/Copyright .*/Copyright OpenRC Authors/
> > 
> > i'm saying you can't do that
>  
>  That's the first part, the second part is to have an Authors file at
>  the top level that lists all of the authors and refer to that in the
>  copyright statement, see the license branch of the main github repo and
>  let me know if this is legal. The site I linked seems to think so
>  because I'm not deleting copyright attributions, just moving them around.

i don't think it's kosher.  just reach out to Roy and see if he's OK
with it and that'll avoid any ambiguity.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Use GLEP27!

[Mike Frysinger]

On 15 Dec 2015 10:35, Alec Warner wrote:
> On Tue, Dec 15, 2015 at 6:19 AM, Mike Frysinger wrote:
> > a flat text file akin to /etc/passwd is not readable.  xml is readable.
> 
> u trollin' bro?

in this domain, it's harder to screw up xml and not notice (either human or
machine) whereas it's pretty easy to add/omit an extra : and not notice as
the file will be valid from a parsing pov.

quick, off the top of your head, which of these are correct ?
and tell me which field exactly each one is supposed to go to ?
and then reasonably expect new comers to read this and not choke ?
lp:x:4:7::/var/spool/lpd:/bin/false
lp:x:4:7:/var/spool/lpd:/bin/false
lp:x:4:7:/var/spool/lpd::/bin/false
lp:x:4:7::lpd:/bin/false
lp:x:4:7:lpd:/bin/false
lp:x:4:7:lpd::/bin/false

i consider this format simply a different form of hazing except we all lose ;)
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Use GLEP27!

[Mike Frysinger]

On 15 Dec 2015 10:24, Anthony G. Basile wrote:
> i looked through portage code and we do have xml parsing sprinkled
> throughout, mostly in repoman for obvious reasons.  why are we trying to
> avoid xml?  to be honest i don't have strong feelings about either the
> flat file (a la /etc/passwd) or xml.
> 
> i'm interested in this because the hardened-sources kernel does make use
> of some special uid/gids.  gengor pointed me to glep 27 and suggested
> that i implement it but i wasn't that interested.  still, it would clean
> up the hardened.

i don't think XML adds that much over RST, and are trivial to parse, both
on an ad-hoc basis, as well as python has modules to enable it.  i think
most people would agree RST or flat text files are less verbose than XML
w/out really losing that much (if anything).  at the time i was thinking
XML purely because we were much more of an XML shop at the time (we had
guidexml and metadata.xml), but with the rise of wiki/github/glep and the
fall of guidexml, the project has moved on.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Use GLEP27!

[Mike Frysinger]

On 15 Dec 2015 22:35, Ulrich Mueller wrote:
> Whatever the format will be, the more important question is where this
> would be implemented:
> 
> - In the package manager, with user and group definition in profiles.
>   This seems to be what GLEP 27 suggests, and as far as I can see, it
>   would require an EAPI bump. Certainly doable, but last time we
>   bumped profiles to a new EAPI we had a rather long transition
>   period.
> 
> - In user.eclass, which could be extended to use the EUSERS and
>   EGROUPS variables defined in ebuilds. The problem is, where would
>   one store the user and group definitions then? Profiles cannot be
>   accessed from an eclass.

long term, i think profiles are better to hold the db as it provides for
clean stacking and is trivial for site-specific extension/control, as well
as image builders via something like catalyst.

short/mid term, i was thinking of writing a new package that holds the db
and tools to query/manage it.  user.eclass would DEPEND on it and ask it
for details, perhaps even doing the actual fs updates (the bash code here
is not pretty wrt locks and python would be much nicer).  that tool could
even search additional site paths (like /usr/local) to locate overrides.

the API to ebuilds/eclasses would be unchanged.  in CrOS, we only look at
the first argument (the user/group name) and load all other details from
the db.  we could seamlessly migrate over existing ebuilds by opting in to
this simpler form.

maybe the short/mid term solution is enough to not get into profile mess
even if i think it's the correct data storage location.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] rfc: OpenRC public API definition

[Mike Frysinger]

On 03 Dec 2015 11:36, William Hubbs wrote:
> 1) All definitions in rc.h, even though they are not formally documented
> in man pages.

this.  if it's not meant to be public, it should have been in librc.h or
a similar internal header.

> I'm bringing this up, because I am looking at redesigning one of the
> undocumented functions soon, and the redesign will definitely break
> things if people are using the function outside of OpenRC.

bump the SONAME and forget about it.  as mentioned in the other thread,
there's not really any consumers today.  plus, i'm pretty sure we've
broken things a bit in the past but no one noticed/complained.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Use GLEP27!

[Mike Frysinger]

On 15 Dec 2015 15:56, Ulrich Mueller wrote:
> >>>>> On Tue, 15 Dec 2015, Mike Frysinger wrote:
> 
> > a flat text file akin to /etc/passwd is not readable.  xml is readable.
> 
> ESR's case study about the password file format seems to disagree:
> http://www.catb.org/esr/writings/taoup/html/ch05s01.html#id2901332

because you cited it, i read it anyways.  that document is about how text
formats should be preferred over binary formats because they do not require
custom tools to modify/update, and because it's easier for binary formats
to screw themselves over from a portability/extensible pov.  it does not
champion the passwd format all by itself, and even says that it's a bit
rigid, and you should consider tagged formats if you want something more.
which we do.

see also the example i posted to Alec as why the format is hostile to devs
whereas my simple RST proposal has none of these issues.

we also know the format works because it's been in use by CrOS for two
years now, including:
(1) profile stacking/overrides
(2) marking users as "dead"
(3) tools to verify/check consistency at rest
(4) parallel installs
(5) correct handling of ROOT and SYSROOT
although 4/5 were written only with Linux/flat files in mind, so they do
not support other OS's or account formats (e.g. ldap/etc...).  i imagine
we'll need to merge with the existing user.eclass logic rather than drop
in replace.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Use GLEP27!

[Mike Frysinger]

On 15 Dec 2015 20:23, Anthony G. Basile wrote:
> On 12/15/15 4:55 PM, Mike Frysinger wrote:
> > On 15 Dec 2015 22:35, Ulrich Mueller wrote:
> >> Whatever the format will be, the more important question is where this
> >> would be implemented:
> >>
> >> - In the package manager, with user and group definition in profiles.
> >>   This seems to be what GLEP 27 suggests, and as far as I can see, it
> >>   would require an EAPI bump. Certainly doable, but last time we
> >>   bumped profiles to a new EAPI we had a rather long transition
> >>   period.
> >>
> >> - In user.eclass, which could be extended to use the EUSERS and
> >>   EGROUPS variables defined in ebuilds. The problem is, where would
> >>   one store the user and group definitions then? Profiles cannot be
> >>   accessed from an eclass.
> >
> > long term, i think profiles are better to hold the db as it provides for
> > clean stacking and is trivial for site-specific extension/control, as well
> > as image builders via something like catalyst.
> >
> > short/mid term, i was thinking of writing a new package that holds the db
> > and tools to query/manage it.  user.eclass would DEPEND on it and ask it
> > for details, perhaps even doing the actual fs updates (the bash code here
> > is not pretty wrt locks and python would be much nicer).  that tool could
> > even search additional site paths (like /usr/local) to locate overrides.
> 
> how do we get our own uid/gid's in there for our packages?  just open a
> bug against the new package?

i would open the git repo to all devs and just let anyone push directly
and roll releases.  maybe just push a tag and that's what the ebuild would
hit.  no need to be gate keepers here since we don't today w/ebuilds and
calls to enew{user,group}.

the question is how to handle the tools.  i'm thinking we should have two
distinct packages so the db could be completely overridden by overlays.

the tools could be in the same repo or a sep one.  i don't feel strongly
either way as we'd just mark base-system@ as the maintaining herd.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Use GLEP27!

[Mike Frysinger]

On 15 Dec 2015 07:28, Ulrich Mueller wrote:
> >>>>> On Tue, 15 Dec 2015, Mike Frysinger wrote:
> 
> > On 14 Dec 2015 21:22, Ulrich Mueller wrote:
> >> The spec seems incomplete. I cannot find a description of the user and
> >> group files' format. (But in fact, there is a standard format which
> >> suggests itself, namely that of the passwd(5) and group(5) files.)
> 
> > i recall going with xml at the time, but i can't find reference to it.
> 
> So the package manager would have to parse XML? We have tried to avoid
> that, so far.

not entirely accurate considering we have metadata.xml

> >> Also having whole directory trees seems wasteful and doesn't fit so
> >> well into the existing design of profiles. It might be simpler to put
> >> "user" (or "passwd") and "group" files directly in the profile.
> >> (If directories are really needed, we could use the scheme foreseen
> >> in [1] for package.* and use.* files.)
> 
> > we implemented this GLEP in Chromium OS and have been using it for a while:
> > https://chromium.googlesource.com/chromiumos/overlays/eclass-overlay/+/master
> 
> > having a directory of files is way more user friendly imo and allows for
> > a format that is easier to read.  /etc/passwd and /etc/group format are
> > not that easy to scan and aren't portable.
> 
> As we most likely will introduce profile file directories in EAPI 7
> (see bug 282296), I'd rather use the same scheme for the user and
> group files, but not something different.

a flat text file akin to /etc/passwd is not readable.  xml is readable.

a markdown like format would work -- easy to parse by machines & humans
and is a single stackable file.
user:ntp
uid:203
gid:203
user:man
uid:13
gid:13
(using : as delimiter since that's what *NIX uses in /etc/passwd)

the main one would grow probably to about 2000+ lines (~400 users in the
tree and each entry takes ~4 lines assuming we enforce eliding of defaults)
which isn't that terrible.  CrOS has a python script already for validating
the db consistency.

> >> Also a mechanism how a subprofile could undefine a user or group
> >> defined in its parent seems to be missing.
> 
> > what exactly do you mean by that ?  you want to make it so attempts to
> > use the account yield an undefined error ?  or you want to have it so
> > a child can revert back to an earlier definition ?
> 
> The former.

we already handle this in CrOS by explicitly including a flag in the file:
defunct:true

thus the PM need not care about the status when locating files or otherwise
include any special handling.  if the last file you hit is marked as defunct,
then enew{user,group} will throw an error when they're called.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Use GLEP27!

[Mike Frysinger]

On 15 Dec 2015 16:00, Michał Górny wrote:
> On Tue, 15 Dec 2015 15:56:34 +0100 Ulrich Mueller wrote:
> > >>>>> On Tue, 15 Dec 2015, Mike Frysinger wrote:  
> > 
> > > a flat text file akin to /etc/passwd is not readable.  xml is readable.  
> > 
> > ESR's case study about the password file format seems to disagree:
> > http://www.catb.org/esr/writings/taoup/html/ch05s01.html#id2901332
> > 
> > I think the name:password:uid:gid:gecos:directory:shell format is
> > readable well enough for human eyes. Certainly it is machine readable;
> > even with standard tools like fgetpwent(3) (or its equivalent in other
> > programming languages).
> 
> Alternatively we could go for whitespace-separated, like fstab. Column
> aligning even more.

we cannot because whitespace is valid, and we use it already in fields
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Use GLEP27!

[Mike Frysinger]

On 15 Dec 2015 15:33, Michał Górny wrote:
> On Tue, 15 Dec 2015 09:19:36 -0500 Mike Frysinger wrote:
> > On 15 Dec 2015 07:28, Ulrich Mueller wrote:
> > > >>>>> On Tue, 15 Dec 2015, Mike Frysinger wrote:  
> > >   
> > > > On 14 Dec 2015 21:22, Ulrich Mueller wrote:  
> > > >> The spec seems incomplete. I cannot find a description of the user and
> > > >> group files' format. (But in fact, there is a standard format which
> > > >> suggests itself, namely that of the passwd(5) and group(5) files.)  
> > >   
> > > > i recall going with xml at the time, but i can't find reference to it.  
> > > 
> > > So the package manager would have to parse XML? We have tried to avoid
> > > that, so far.  
> > 
> > not entirely accurate considering we have metadata.xml
> 
> Not entirely accurate considering the contents of metadata.xml are not
> necessary to build and install packages.

read the context.  your statement is fairly obvious.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Use GLEP27!

[Mike Frysinger]

On 15 Dec 2015 15:56, Ulrich Mueller wrote:
> >>>>> On Tue, 15 Dec 2015, Mike Frysinger wrote:
> 
> > a flat text file akin to /etc/passwd is not readable.  xml is readable.
> 
> ESR's case study about the password file format seems to disagree:
> http://www.catb.org/esr/writings/taoup/html/ch05s01.html#id2901332

i don't generally find anything ESR has to say useful, and his code even
less so

> I think the name:password:uid:gid:gecos:directory:shell format is
> readable well enough for human eyes.

having looked at way too many of these, i disagree.  it's harder (imo) to
scan due to the lack of alignment, it's more of a pita to deal with defaults,
and it doesn't permit for additional metadata like i already quoted (the
defunct field).

> Certainly it is machine readable;
> even with standard tools like fgetpwent(3) (or its equivalent in other
> programming languages).

again, not portable.  the format proposed is also trivial to parse by
python and awk.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: converting copyright/license information in OpenRC

[Mike Frysinger]

On 11 Dec 2015 14:16, Patrick McLean wrote:
> On Fri, 11 Dec 2015 15:37:48 -0600 William Hubbs wrote:
> > On Fri, Dec 11, 2015 at 09:04:47PM +0100, Ulrich Mueller wrote:
> > > > On Fri, 11 Dec 2015, William Hubbs wrote:  
> > >   
> > Well, the OpenRC project is currently inconsistent about this, so the
> > intention is to make it consistent.
> > 
> >  The .c/.h files have file-scope licenses, but that isn't true for
> >  everything in the project.
> > 
> > I am willing to make the effort to do this, I was just wondering if
> > there are any legal pitfalls I need to worry about.
> > 
> > My theory is I can probably use git to find out who all of the authors
> > are, and generate an Authors list from that information and from
> > looking at copyright notices.
> 
> One concern about this is the possibility of copied code. If OpenRC
> ever copied code from other BSD licensed projects, then dropping the
> notice from the top of the file would be a violation of the upstream
> license.

OpenRC isn't purely Gentoo copyright, so it's already a violation.
the majority of entries belong to Roy.
-mike


signature.asc
Description: Digital signature