[gentoo-portage-dev] [PATCH eapi6-pt2 v2 3/6] Add sandbox directory removal functions for EAPI 7

[Michał Górny]

Bug: https://bugs.gentoo.org/630422
---
 bin/eapi.sh|  4 
 bin/ebuild.sh  | 17 +
 bin/save-ebuild-env.sh |  1 +
 3 files changed, 22 insertions(+)

diff --git a/bin/eapi.sh b/bin/eapi.sh
index 67563bed8..5d77c8daf 100644
--- a/bin/eapi.sh
+++ b/bin/eapi.sh
@@ -104,6 +104,10 @@ ___eapi_has_in_iuse() {
[[ ! ${1-${EAPI-0}} =~ 
^(0|1|2|3|4|4-python|4-slot-abi|5|5-hdepend|5-progress)$ ]]
 }
 
+___eapi_has_sandbox_rm_functions() {
+   [[ ! ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-python|4-slot-abi|5|5-progress|6)$ 
]]
+}
+
 ___eapi_has_master_repositories() {
[[ ${1-${EAPI-0}} =~ ^(5-progress)$ ]]
 }
diff --git a/bin/ebuild.sh b/bin/ebuild.sh
index d63b0a0ba..9194d21d7 100755
--- a/bin/ebuild.sh
+++ b/bin/ebuild.sh
@@ -147,6 +147,17 @@ __sb_append_var() {
[[ -z $1 || -n $2 ]] && die "Usage: add$(LC_ALL=C tr "[:upper:]" 
"[:lower:]" <<< "${_v}") "
export ${var}="${!var:+${!var}:}$1"
 }
+__sb_remove_var() {
+   local _v=$1 ; shift
+   local var="SANDBOX_${_v}"
+   [[ -z $1 || -n $2 ]] && die "Usage: add$(LC_ALL=C tr "[:upper:]" 
"[:lower:]" <<< "${_v}") "
+   local vv=:${!var}:
+   vv=${vv//:$1:/}
+   # strip leading and trailing colon now
+   vv=${vv##:}
+   vv=${vv%%:}
+   export ${var}="${vv}"
+}
 # bash-4 version:
 # local var="SANDBOX_${1^^}"
 # addread() { __sb_append_var ${0#add} "$@" ; }
@@ -154,6 +165,12 @@ addread(){ __sb_append_var READ"$@" ; }
 addwrite()   { __sb_append_var WRITE   "$@" ; }
 adddeny(){ __sb_append_var DENY"$@" ; }
 addpredict() { __sb_append_var PREDICT "$@" ; }
+if ___eapi_has_sandbox_rm_functions; then
+   rmread() { __sb_remove_var READ"$@" ; }
+   rmwrite(){ __sb_remove_var WRITE   "$@" ; }
+   rmdeny() { __sb_remove_var DENY"$@" ; }
+   rmpredict()  { __sb_remove_var PREDICT "$@" ; }
+fi
 
 addwrite "${PORTAGE_TMPDIR}"
 addread "/:${PORTAGE_TMPDIR}"
diff --git a/bin/save-ebuild-env.sh b/bin/save-ebuild-env.sh
index e5ae8af88..9bd0445e2 100644
--- a/bin/save-ebuild-env.sh
+++ b/bin/save-ebuild-env.sh
@@ -55,6 +55,7 @@ __save_ebuild_env() {
__has_phase_defined_up_to \
hasv hasq __qa_source __qa_call \
addread addwrite adddeny addpredict __sb_append_var \
+   rmread rmwrite rmdeny rmpredict __sb_remove_var \
use usev useq has_version portageq \
best_version use_with use_enable register_die_hook \
unpack __strip_duplicate_slashes econf einstall \
-- 
2.16.2

[gentoo-portage-dev] [PATCH eapi6-pt2 v2 4/6] Add EAPI 7 version comparison & manipulation functions

[Michał Górny]

Bug: https://bugs.gentoo.org/482170
---
 bin/eapi.sh   |   4 +
 bin/eapi7-ver-funcs.sh| 191 
 bin/isolated-functions.sh |   4 +
 pym/portage/tests/bin/test_eapi7_ver_funcs.py | 240 ++
 4 files changed, 439 insertions(+)
 create mode 100644 bin/eapi7-ver-funcs.sh
 create mode 100644 pym/portage/tests/bin/test_eapi7_ver_funcs.py

diff --git a/bin/eapi.sh b/bin/eapi.sh
index 5d77c8daf..cd2acad80 100644
--- a/bin/eapi.sh
+++ b/bin/eapi.sh
@@ -108,6 +108,10 @@ ___eapi_has_sandbox_rm_functions() {
[[ ! ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-python|4-slot-abi|5|5-progress|6)$ 
]]
 }
 
+___eapi_has_version_functions() {
+   [[ ! ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-python|4-slot-abi|5|5-progress|6)$ 
]]
+}
+
 ___eapi_has_master_repositories() {
[[ ${1-${EAPI-0}} =~ ^(5-progress)$ ]]
 }
diff --git a/bin/eapi7-ver-funcs.sh b/bin/eapi7-ver-funcs.sh
new file mode 100644
index 0..b4e98f4e7
--- /dev/null
+++ b/bin/eapi7-ver-funcs.sh
@@ -0,0 +1,191 @@
+#!/bin/bash
+# Copyright 1999-2018 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+__eapi7_ver_parse_range() {
+   local range=${1}
+   local max=${2}
+
+   [[ ${range} == [0-9]* ]] \
+   || die "${FUNCNAME}: range must start with a number"
+   start=${range%-*}
+   [[ ${range} == *-* ]] && end=${range#*-} || end=${start}
+   if [[ ${end} ]]; then
+   [[ ${start} -le ${end} ]] \
+   || die "${FUNCNAME}: end of range must be >= start"
+   [[ ${end} -le ${max} ]] || end=${max}
+   else
+   end=${max}
+   fi
+}
+
+__eapi7_ver_split() {
+   local v=${1} LC_ALL=C
+
+   comp=()
+
+   # get separators and components
+   local s c
+   while [[ ${v} ]]; do
+   # cut the separator
+   s=${v%%[a-zA-Z0-9]*}
+   v=${v:${#s}}
+   # cut the next component; it can be either digits or letters
+   [[ ${v} == [0-9]* ]] && c=${v%%[^0-9]*} || c=${v%%[^a-zA-Z]*}
+   v=${v:${#c}}
+
+   comp+=( "${s}" "${c}" )
+   done
+}
+
+ver_cut() {
+   local range=${1}
+   local v=${2:-${PV}}
+   local start end
+   local -a comp
+
+   __eapi7_ver_split "${v}"
+   local max=$((${#comp[@]}/2))
+   __eapi7_ver_parse_range "${range}" "${max}"
+
+   local IFS=
+   if [[ ${start} -gt 0 ]]; then
+   start=$(( start*2 - 1 ))
+   fi
+   echo "${comp[*]:start:end*2-start}"
+}
+
+ver_rs() {
+   local v
+   (( ${#} & 1 )) && v=${@: -1} || v=${PV}
+   local start end i
+   local -a comp
+
+   __eapi7_ver_split "${v}"
+   local max=$((${#comp[@]}/2 - 1))
+
+   while [[ ${#} -ge 2 ]]; do
+   __eapi7_ver_parse_range "${1}" "${max}"
+   for (( i = start*2; i <= end*2; i+=2 )); do
+   [[ ${i} -eq 0 && -z ${comp[i]} ]] && continue
+   comp[i]=${2}
+   done
+   shift 2
+   done
+
+   local IFS=
+   echo "${comp[*]}"
+}
+
+__eapi7_ver_compare_int() {
+   local a=$1 b=$2 d=$(( ${#1}-${#2} ))
+
+   # Zero-pad to equal length if necessary.
+   if [[ ${d} -gt 0 ]]; then
+   printf -v b "%0${d}d%s" 0 "${b}"
+   elif [[ ${d} -lt 0 ]]; then
+   printf -v a "%0$(( -d ))d%s" 0 "${a}"
+   fi
+
+   [[ ${a} > ${b} ]] && return 3
+   [[ ${a} == "${b}" ]]
+}
+
+__eapi7_ver_compare() {
+   local va=${1} vb=${2} a an al as ar b bn bl bs br re LC_ALL=C
+
+   
re="^([0-9]+(\.[0-9]+)*)([a-z]?)((_(alpha|beta|pre|rc|p)[0-9]*)*)(-r[0-9]+)?$"
+
+   [[ ${va} =~ ${re} ]] || die "${FUNCNAME}: invalid version: ${va}"
+   an=${BASH_REMATCH[1]}
+   al=${BASH_REMATCH[3]}
+   as=${BASH_REMATCH[4]}
+   ar=${BASH_REMATCH[7]}
+
+   [[ ${vb} =~ ${re} ]] || die "${FUNCNAME}: invalid version: ${vb}"
+   bn=${BASH_REMATCH[1]}
+   bl=${BASH_REMATCH[3]}
+   bs=${BASH_REMATCH[4]}
+   br=${BASH_REMATCH[7]}
+
+   # Compare numeric components (PMS algorithm 3.2)
+   # First component
+   __eapi7_ver_compare_int "${an%%.*}" "${bn%%.*}" || return
+
+   while [[ ${an} == *.* && ${bn} == *.* ]]; do
+   # Other components (PMS algorithm 3.3)
+   an=${an#*.}
+   bn=${bn#*.}
+   a=${an%%.*}
+   b=${bn%%.*}
+   if [[ ${a} == 0* || ${b} == 0* ]]; then
+   # Remove any trailing zeros
+   [[ ${a} =~ 0+$ ]] && a=${a%"${BASH_REMATCH[0]}"}
+   [[ ${b} =~ 0+$ ]] && b=${b%"${BASH_REMATCH[0]}"}
+   [[ ${a} > ${b} ]] && return 3
+   [[ ${a} < ${b} ]] && return 1
+   else
+   __eapi7_ver_compare_int "${a}" "${b}" || 

[gentoo-portage-dev] [PATCH eapi6-pt2 v2 6/6] Do not export PORTDIR & ECLASSDIR in EAPI 7

[Michał Górny]

Bug: https://bugs.gentoo.org/373349
Bug: https://bugs.gentoo.org/373351
---
 bin/eapi.sh|  4 
 bin/phase-functions.sh |  6 --
 pym/portage/eapi.py| 11 +++
 pym/portage/package/ebuild/doebuild.py | 14 ++
 4 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/bin/eapi.sh b/bin/eapi.sh
index 3e837f19d..9fa96548b 100644
--- a/bin/eapi.sh
+++ b/bin/eapi.sh
@@ -38,6 +38,10 @@ ___eapi_has_RDEPEND_DEPEND_fallback() {
[[ ${1-${EAPI-0}} =~ ^(0|1|2|3)$ ]]
 }
 
+___eapi_has_PORTDIR_ECLASSDIR() {
+   [[ ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-python|4-slot-abi|5|5-progress|6)$ ]]
+}
+
 # HELPERS PRESENCE
 
 ___eapi_has_dohard() {
diff --git a/bin/phase-functions.sh b/bin/phase-functions.sh
index d95012d6b..017dc132b 100644
--- a/bin/phase-functions.sh
+++ b/bin/phase-functions.sh
@@ -12,7 +12,7 @@ PORTAGE_READONLY_METADATA="DEFINED_PHASES DEPEND DESCRIPTION
PDEPEND PROVIDE RDEPEND REPOSITORY RESTRICT SLOT SRC_URI"
 
 PORTAGE_READONLY_VARS="D EBUILD EBUILD_PHASE EBUILD_PHASE_FUNC \
-   EBUILD_SH_ARGS ECLASSDIR EMERGE_FROM FILESDIR MERGE_TYPE \
+   EBUILD_SH_ARGS EMERGE_FROM FILESDIR MERGE_TYPE \
PM_EBUILD_HOOK_DIR \
PORTAGE_ACTUAL_DISTDIR PORTAGE_ARCHLIST PORTAGE_BASHRC  \
PORTAGE_BINPKG_FILE PORTAGE_BINPKG_TAR_OPTS PORTAGE_BINPKG_TMPFILE \
@@ -30,7 +30,6 @@ PORTAGE_READONLY_VARS="D EBUILD EBUILD_PHASE 
EBUILD_PHASE_FUNC \
PORTAGE_SAVED_READONLY_VARS PORTAGE_SIGPIPE_STATUS \
PORTAGE_TMPDIR PORTAGE_UPDATE_ENV PORTAGE_USERNAME \
PORTAGE_VERBOSE PORTAGE_WORKDIR_MODE PORTAGE_XATTR_EXCLUDE \
-   PORTDIR \
REPLACING_VERSIONS REPLACED_BY_VERSION T WORKDIR \
__PORTAGE_HELPER __PORTAGE_TEST_HARDLINK_LOCKS"
 
@@ -106,6 +105,9 @@ __filter_readonly_variables() {
if ___eapi_has_prefix_variables; then
filtered_vars+=" ED EPREFIX EROOT"
fi
+   if ___eapi_has_PORTDIR_ECLASSDIR; then
+   filtered_vars+=" PORTDIR ECLASSDIR"
+   fi
 
if has --filter-sandbox $* ; then
filtered_vars="${filtered_vars} SANDBOX_.*"
diff --git a/pym/portage/eapi.py b/pym/portage/eapi.py
index 092780ded..5613fb5d2 100644
--- a/pym/portage/eapi.py
+++ b/pym/portage/eapi.py
@@ -47,6 +47,14 @@ def eapi_exports_replace_vars(eapi):
 def eapi_exports_EBUILD_PHASE_FUNC(eapi):
return eapi not in ("0", "1", "2", "3", "4", "4-python", "4-slot-abi")
 
+def eapi_exports_PORTDIR(eapi):
+   return eapi in ("0", "1", "2", "3", "4", "4-python", "4-slot-abi",
+   "5", "5-progress", "6")
+
+def eapi_exports_ECLASSDIR(eapi):
+   return eapi in ("0", "1", "2", "3", "4", "4-python", "4-slot-abi",
+   "5", "5-progress", "6")
+
 def eapi_exports_REPOSITORY(eapi):
return eapi in ("4-python", "5-progress")
 
@@ -105,6 +113,7 @@ def eapi_empty_groups_always_true(eapi):
 
 _eapi_attrs = collections.namedtuple('_eapi_attrs',
'dots_in_PN dots_in_use_flags exports_EBUILD_PHASE_FUNC '
+   'exports_PORTDIR exports_ECLASSDIR '
'feature_flag_test feature_flag_targetroot '
'hdepend iuse_defaults iuse_effective posixish_locale '
'repo_deps required_use required_use_at_most_one_of slot_operator 
slot_deps '
@@ -134,6 +143,8 @@ def _get_eapi_attrs(eapi):
dots_in_use_flags = (eapi is None or 
eapi_allows_dots_in_use_flags(eapi)),
empty_groups_always_true = (eapi is not None and 
eapi_empty_groups_always_true(eapi)),
exports_EBUILD_PHASE_FUNC = (eapi is None or 
eapi_exports_EBUILD_PHASE_FUNC(eapi)),
+   exports_PORTDIR = (eapi is not None and 
eapi_exports_PORTDIR(eapi)),
+   exports_ECLASSDIR = (eapi is not None and 
eapi_exports_ECLASSDIR(eapi)),
feature_flag_test = True,
feature_flag_targetroot = (eapi is not None and 
eapi_has_targetroot(eapi)),
hdepend = (eapi is not None and eapi_has_hdepend(eapi)),
diff --git a/pym/portage/package/ebuild/doebuild.py 
b/pym/portage/package/ebuild/doebuild.py
index 8c8f373bf..92db04868 100644
--- a/pym/portage/package/ebuild/doebuild.py
+++ b/pym/portage/package/ebuild/doebuild.py
@@ -57,10 +57,11 @@ from portage.data import portage_gid, portage_uid, secpass, 
\
 from portage.dbapi.porttree import _parse_uri_map
 from portage.dep import Atom, check_required_use, \
human_readable_required_use, paren_enclose, use_reduce
-from portage.eapi import eapi_exports_KV, eapi_exports_merge_type, \
-   eapi_exports_replace_vars, eapi_exports_REPOSITORY, \
-   eapi_has_required_use, eapi_has_src_prepare_and_src_configure, \
-   eapi_has_pkg_pretend, _get_eapi_attrs
+from portage.eapi import (eapi_exports_KV, eapi_exports_merge_type,
+   eapi_exports_replace_vars, eapi_exports_REPOSITORY,
+   eapi_has_required_use, eapi_has_src_prepare_and_src_configure,
+   

[gentoo-portage-dev] [PATCH eapi6-pt2 v2 5/6] Support ENV_UNSET for EAPI 7

[Michał Górny]

Bug: https://bugs.gentoo.org/499288
---
 bin/eapi.sh| 4 
 bin/ebuild.sh  | 6 ++
 pym/_emerge/actions.py | 4 ++--
 pym/portage/const.py   | 3 ++-
 4 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/bin/eapi.sh b/bin/eapi.sh
index cd2acad80..3e837f19d 100644
--- a/bin/eapi.sh
+++ b/bin/eapi.sh
@@ -223,3 +223,7 @@ ___eapi_bash_3_2() {
 ___eapi_bash_4_2() {
! ___eapi_bash_3_2 "$@"
 }
+
+___eapi_has_ENV_UNSET() {
+   [[ ! ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-python|4-slot-abi|5|5-progress|6)$ 
]]
+}
diff --git a/bin/ebuild.sh b/bin/ebuild.sh
index 9194d21d7..41b12b508 100755
--- a/bin/ebuild.sh
+++ b/bin/ebuild.sh
@@ -137,6 +137,12 @@ shift $#
 
 # Unset some variables that break things.
 unset GZIP BZIP BZIP2 CDPATH GREP_OPTIONS GREP_COLOR GLOBIGNORE
+if ___eapi_has_ENV_UNSET; then
+   for x in ${ENV_UNSET}; do
+   unset "${x}"
+   done
+   unset x
+fi
 
 [[ $PORTAGE_QUIET != "" ]] && export PORTAGE_QUIET
 
diff --git a/pym/_emerge/actions.py b/pym/_emerge/actions.py
index 97df9f716..2293560c1 100644
--- a/pym/_emerge/actions.py
+++ b/pym/_emerge/actions.py
@@ -1,4 +1,4 @@
-# Copyright 1999-2016 Gentoo Foundation
+# Copyright 1999-2018 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 from __future__ import division, print_function, unicode_literals
@@ -1817,7 +1817,7 @@ def action_info(settings, trees, myopts, myfiles):
myvars = list(settings)
else:
myvars = ['GENTOO_MIRRORS', 'CONFIG_PROTECT', 
'CONFIG_PROTECT_MASK',
- 'DISTDIR', 'PKGDIR', 'PORTAGE_TMPDIR',
+ 'DISTDIR', 'ENV_UNSET', 'PKGDIR', 'PORTAGE_TMPDIR',
  'PORTAGE_BUNZIP2_COMMAND',
  'PORTAGE_BZIP2_COMMAND',
  'USE', 'CHOST', 'CFLAGS', 'CXXFLAGS',
diff --git a/pym/portage/const.py b/pym/portage/const.py
index 655be82b1..16922a5e6 100644
--- a/pym/portage/const.py
+++ b/pym/portage/const.py
@@ -1,5 +1,5 @@
 # portage: Constants
-# Copyright 1998-2014 Gentoo Foundation
+# Copyright 1998-2018 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 from __future__ import unicode_literals
@@ -89,6 +89,7 @@ INCREMENTALS = (
"ACCEPT_KEYWORDS",
"CONFIG_PROTECT",
"CONFIG_PROTECT_MASK",
+   "ENV_UNSET",
"FEATURES",
"IUSE_IMPLICIT",
"PRELINK_PATH",
-- 
2.16.2

[gentoo-portage-dev] [PATCH eapi6-pt2 v2 2/6] nonfatal: Implement fallback executable for EAPI 7

[Michał Górny]

EAPI 7 specifies that nonfatal has to be implemented both as a bash
function and a fallback executable, so that it can be used e.g. via
find/xargs.

Bug: https://bugs.gentoo.org/622894
---
 bin/eapi.sh |  4 
 bin/ebuild-helpers/nonfatal | 14 ++
 2 files changed, 18 insertions(+)
 create mode 100755 bin/ebuild-helpers/nonfatal

diff --git a/bin/eapi.sh b/bin/eapi.sh
index fa254485c..67563bed8 100644
--- a/bin/eapi.sh
+++ b/bin/eapi.sh
@@ -72,6 +72,10 @@ ___eapi_has_nonfatal() {
[[ ! ${1-${EAPI-0}} =~ ^(0|1|2|3)$ ]]
 }
 
+___eapi_has_nonfatal_as_executable() {
+   [[ ! ${1-${EAPI-0}} =~ 
^(0|1|2|3|4|4-python|4-slot-abi|5|5-hdepend|5-progress|6)$ ]]
+}
+
 ___eapi_has_doheader() {
[[ ! ${1-${EAPI-0}} =~ ^(0|1|2|3|4|4-python|4-slot-abi)$ ]]
 }
diff --git a/bin/ebuild-helpers/nonfatal b/bin/ebuild-helpers/nonfatal
new file mode 100755
index 0..4cb9ae77a
--- /dev/null
+++ b/bin/ebuild-helpers/nonfatal
@@ -0,0 +1,14 @@
+#!/bin/bash
+# Copyright 1999-2017 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+source "${PORTAGE_BIN_PATH}"/isolated-functions.sh || exit 1
+
+if ! ___eapi_has_nonfatal_as_executable; then
+   die "${0##*/} not supported as fallback helper in this EAPI"
+fi
+if [[ $# -lt 1 ]]; then
+   die "${0##*/}: Missing argument"
+fi
+
+PORTAGE_NONFATAL=1 exec "$@"
-- 
2.16.2

[gentoo-portage-dev] [PATCH eapi6-pt2 v2 1/6] Allow package.*, use.* directories in EAPI 7

[Michał Górny]

Bug: https://bugs.gentoo.org/282296
---
 pym/portage/eapi.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pym/portage/eapi.py b/pym/portage/eapi.py
index 075f7a59c..092780ded 100644
--- a/pym/portage/eapi.py
+++ b/pym/portage/eapi.py
@@ -85,7 +85,7 @@ def eapi_supports_stable_use_forcing_and_masking(eapi):
return eapi not in ("0", "1", "2", "3", "4", "4-python", "4-slot-abi")
 
 def eapi_allows_directories_on_profile_level_and_repository_level(eapi):
-   return eapi in ("4-python", "5-progress")
+   return eapi not in ("0", "1", "2", "3", "4", "4-slot-abi", "5", "6")
 
 def eapi_has_use_aliases(eapi):
return eapi in ("4-python", "5-progress")
-- 
2.16.2

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

[Rich Freeman]

On Thu, Mar 8, 2018 at 9:11 PM, R0b0t1  wrote:
>
> Sadly interest in the patches seems to have waned. The functionality
> is not exactly duplicated in containers, but they do make it easier to
> find changes.
>

Well, the idea with containers wouldn't be to monitor anything, but
instead to ensure that there is nothing in the container the ebuild
shouldn't need.  If the package declares 3 build-time dependencies
then the container would contain @system plus those three
dependencies.  If the build system chokes then it will choke for
everybody (eg for the maintainer testing the package), and not
randomly when some user doesn't have some package installed that
wasn't declared.

Now, a container wouldn't help with figuring out what the dependencies
actually are.  Besides inspection/etc a quick solution there is to
just do a build without a container and check the linking, then go
back and fix the deps, and then rebuild to verify that nothing else
was needed.

-- 
Rich

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

[R0b0t1]

On Thu, Mar 8, 2018 at 7:06 PM, Rich Freeman  wrote:
> On Thu, Mar 8, 2018 at 7:46 PM, Benda Xu  wrote:
>> Rich Freeman  writes:
>>
>>> If you have util-linux installed then try running (as any user - you
>>> don't have to be root): unshare -i -m -n -p -u -C -f --mount-proc -U
>>> -r /bin/bash
>>>
>>> Congrats.  You are now root in a container.  You're in the same root
>>> filesystem as always.  You'll note that you can't actually see
>>> anything that you couldn't see before.  If you run ps -ea you'll see
>>> that you're the only process running on the system.  Devices like
>>> /dev/sda aren't actually accessible.  A lot of container managers
>>> would mount a new /dev and just hide most of that stuff.  You can
>>> probably imagine how something like this could be useful for isolating
>>> processes.
>>
>> Just a side node, this seems to be the ultimate sandbox we (Gentoo and
>> portage) are after.  With this, we might even be able to have portage
>> full functional: a build is completely determined and only determined by
>> the dependencies and USE flags.
>>
>
> I'm not sure how well this would perform, but I had given this a bit
> of thought a few years ago.  There are two obvious ways to go about
> this: the sandbox or containers.
>

It may be possible to use fanotify(7) (but this would only catch disk
access). There is an extension to fanotify created as someone's thesis
(http://lkml.iu.edu/hypermail/linux/kernel/1703.1/05249.html) that
allows recursive watches. One of the features of fanotify is that it
is possible to deny the events generated. The fanotify API may
simplify the application of the generated rules. It was designed to be
fast, and most processing is done in the kernel when calls are made.

Sadly interest in the patches seems to have waned. The functionality
is not exactly duplicated in containers, but they do make it easier to
find changes.

[gentoo-dev] Feature="test" returns 0 tests

[Lucas Ramage]

Hello,

I am working on upgrading paho-mqtt to the latest release and I have an
issue with enabling tests.

I have FEATURE="test" in an lxc container and I am seeing it run the tests
when I emerge dev-python/paho-mqtt. However, when I committed my changes,
the reviewer is not having any test run when compiling with the same
configuration.

- [Pull Request on Github](https://github.com/gentoo/gentoo/pull/7137)


​Thanks,​

-- 

[image: Visit online journal] 

*Lucas Ramage* / Software Engineer
ramage.lu...@openmailbox.org / (941) 404-6794

*PGP Fingerprint* / Learn More 
EAE7 45DF 818D 4948 DDA7 0F44 F52A 5A96 7B9B 6FB7


*Visit online journal*
http://lramage94.github.io 

[image: Github]  [image: Linkedin]

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

[Rich Freeman]

On Thu, Mar 8, 2018 at 7:46 PM, Benda Xu  wrote:
> Rich Freeman  writes:
>
>> If you have util-linux installed then try running (as any user - you
>> don't have to be root): unshare -i -m -n -p -u -C -f --mount-proc -U
>> -r /bin/bash
>>
>> Congrats.  You are now root in a container.  You're in the same root
>> filesystem as always.  You'll note that you can't actually see
>> anything that you couldn't see before.  If you run ps -ea you'll see
>> that you're the only process running on the system.  Devices like
>> /dev/sda aren't actually accessible.  A lot of container managers
>> would mount a new /dev and just hide most of that stuff.  You can
>> probably imagine how something like this could be useful for isolating
>> processes.
>
> Just a side node, this seems to be the ultimate sandbox we (Gentoo and
> portage) are after.  With this, we might even be able to have portage
> full functional: a build is completely determined and only determined by
> the dependencies and USE flags.
>

I'm not sure how well this would perform, but I had given this a bit
of thought a few years ago.  There are two obvious ways to go about
this: the sandbox or containers.

Either way you first go through the declared dependencies (and @system
under our current policies) and obtain a list of all files installed
by these packages.  Then you either bind mount those files into a
container, or add them to the sandbox configuration as readable.
Right now the sandbox rules are set to allow read access by default on
everything, but this is just a one-liner to change, which would cause
the sandbox to generate an error if a file is read which isn't
explicitly enabled.

The container solution is going to be cleaner because it also helps
curb errors from automagic build systems.  These build systems
wouldn't even be able to detect files not owned by a declared
dependency.  With the sandbox approach those files would be visible,
but would generate errors when accessed (so at least we get a bug
report, but users still have to deal with the issue).  Sure, this
would to some extent hide problems, but then again the automagic build
system would be defeated all the same.

The real question is how long it takes to extract those file lists and
create all those bind mounts.  In the case of @system some of this
could be cached.  I'm pretty sure the file lists would be quite fast -
we only need to go one level deep on the dependency tree (I think).  I
suspect the bind mounts would be fast, but I haven't tried to
benchmark it.  I also have no idea how sandbox performs with a very
long list of rules.

-- 
Rich

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

[Benda Xu]

Rich Freeman  writes:

> If you have util-linux installed then try running (as any user - you
> don't have to be root): unshare -i -m -n -p -u -C -f --mount-proc -U
> -r /bin/bash
>
> Congrats.  You are now root in a container.  You're in the same root
> filesystem as always.  You'll note that you can't actually see
> anything that you couldn't see before.  If you run ps -ea you'll see
> that you're the only process running on the system.  Devices like
> /dev/sda aren't actually accessible.  A lot of container managers
> would mount a new /dev and just hide most of that stuff.  You can
> probably imagine how something like this could be useful for isolating
> processes.  

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

Re: [gentoo-dev] Proliferation of IUSE=static-libs in Gentoo

[Francesco Riosa]

2018-03-08 16:40 GMT+01:00 Michał Górny :

> Hello, developers.
>
> I would like to bring to your attention an alarming trend in Gentoo
> ebuilds -- the proliferation of IUSE=static-libs, that is a flag
> allowing our users to build static libraries.
>
> I should like to remind you that static linking is almost always a bad
> idea. It has serious security implications, it is poorly supported on
> *nix systems (example: library dependencies are provided via hacks, we
> don't have proper rebuild capabilities) and should be basically
> considered  a great evil. Partially relevant doc: [1].
>
> This is why Gentoo does not generally support statically linking stuff,
> and we force dynamic linking whenever possible (sometimes even going too
> far with that but that's another story). We only allow static linking
> for special cases where shared linking can't be used for one reason
> or another.
>
> As part of that we also shouldn't deliver static libraries unless
> absolutely necessary to satisfy the dependencies of applications which
> we support built statically. Back in the day, Gentoo developers were
> pushing against packages that built static libraries unconditionally.
> However, it seems that at some point this front changed from 'fighting
> unconditionally built static libraries' to 'proliferating USE=static-
> libs everywhere'. Which is bad.
>
> So, developers, please *stop adding USE=static-libs* to random libraries
> that have no reason whatever to be statically linked to. And by that I
> mean a good reason, not creeping featurism, not 'user asked for it', not
> 'this broken package hardcodes libfoo.a'.
>

this would make impossible to use qemu static with binfmt alas
https://wiki.debian.org/QemuUserEmulation
Also looking for which packages are eligible for static libraries or not is
more work, not less, because it's a whole different layer of dependancies
(when doing the qemu stuff I just decided to build static for everything
rather than manage use flags per package)

Re: [gentoo-portage-dev] [PATCH] ebuild-helpers: Fix overriding 'insinto' directory

[Zac Medico]

On 03/08/2018 11:51 AM, Michał Górny wrote:
> Closes: https://bugs.gentoo.org/649946
> ---
>  bin/ebuild-helpers/doconfd  | 9 +++--
>  bin/ebuild-helpers/doenvd   | 9 +++--
>  bin/ebuild-helpers/doheader | 6 +-
>  3 files changed, 19 insertions(+), 5 deletions(-)
> 
> diff --git a/bin/ebuild-helpers/doconfd b/bin/ebuild-helpers/doconfd
> index 38cf58234..15ad980f3 100755
> --- a/bin/ebuild-helpers/doconfd
> +++ b/bin/ebuild-helpers/doconfd
> @@ -2,10 +2,15 @@
>  # Copyright 1999-2018 Gentoo Foundation
>  # Distributed under the terms of the GNU General Public License v2
>  
> +source "${PORTAGE_BIN_PATH}"/isolated-functions.sh || exit 1
> +
>  if [[ $# -lt 1 ]] ; then
> - source "${PORTAGE_BIN_PATH}"/isolated-functions.sh || exit 1
>   __helpers_die "${0##*/}: at least one argument needed"
>   exit 1
>  fi
>  
> -_E_INSDESTTREE_='/etc/conf.d/' exec doins "$@"
> +export _E_INSDESTTREE_='/etc/conf.d/'
> +if ___eapi_has_DESTTREE_INSDESTTREE; then
> + export INSDESTTREE=${_E_INSDESTTREE_}
> +fi
> +exec doins "$@"
> diff --git a/bin/ebuild-helpers/doenvd b/bin/ebuild-helpers/doenvd
> index a15cec7f2..f14b95104 100755
> --- a/bin/ebuild-helpers/doenvd
> +++ b/bin/ebuild-helpers/doenvd
> @@ -2,10 +2,15 @@
>  # Copyright 1999-2018 Gentoo Foundation
>  # Distributed under the terms of the GNU General Public License v2
>  
> +source "${PORTAGE_BIN_PATH}"/isolated-functions.sh || exit 1
> +
>  if [[ $# -lt 1 ]] ; then
> - source "${PORTAGE_BIN_PATH}"/isolated-functions.sh || exit 1
>   __helpers_die "${0##*/}: at least one argument needed"
>   exit 1
>  fi
>  
> -_E_INSDESTTREE_='/etc/env.d/' exec doins "$@"
> +export _E_INSDESTTREE_='/etc/env.d/'
> +if ___eapi_has_DESTTREE_INSDESTTREE; then
> + export INSDESTTREE=${_E_INSDESTTREE_}
> +fi
> +exec doins "$@"
> diff --git a/bin/ebuild-helpers/doheader b/bin/ebuild-helpers/doheader
> index 03bf23b1c..aedc2322a 100755
> --- a/bin/ebuild-helpers/doheader
> +++ b/bin/ebuild-helpers/doheader
> @@ -13,4 +13,8 @@ if [[ $# -lt 1 ]] || [[ $1 == -r && $# -lt 2 ]] ; then
>   exit 1
>  fi
>  
> -_E_INSDESTTREE_='/usr/include/' exec doins "$@"
> +export _E_INSDESTTREE_='/usr/include/'
> +if ___eapi_has_DESTTREE_INSDESTTREE; then
> + export INSDESTTREE=${_E_INSDESTTREE_}
> +fi
> +exec doins "$@"
> 

Looks good, please merge.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

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

[Rich Freeman]

On Thu, Mar 8, 2018 at 4:00 PM, R0b0t1  wrote:
> On Thu, Mar 8, 2018 at 11:50 AM, Rich Freeman  wrote:
>> If you have util-linux installed then try running (as any user - you
>> don't have to be root):
>> unshare -i -m -n -p -u -C -f --mount-proc -U -r  /bin/bash
>>
>
> Interesting. I hadn't found a good interface to containers and
> clone(2) besides Docker. Of course, I didn't look very hard. I half
> expect a "new" process model to develop around the kernel namespaces,
> as people realize GID separation only is too coarse.

Well, the original userspace tools are in app-emulation/lxc (I can see
how it ended up in this category, but obviously it doesn't fit).

Docker is the most popular one.

My personal favorite is systemd-nspawn.  That basically has almost
nothing to do with systemd per-se, but I have no idea if it can work
standalone.  It is a bit more minimal while still being fairly
functional.

unshare/nsenter are the util-linux commands that give relatively
direct access to the system calls themselves.  I used unshare to
illustrate that these really are just system calls and how you use
them is up to you.

>
> I still see some odd claims about container security, though: claiming
> containers are more secure than user accounts still seems odd to me,
> as if you don't trust the kernel to enforce user accounts, why trust
> it to enforce namespace separation?
>

I'm not sure I'd say that containers are more than user accounts
per-se, though with UID mapping it could be easier to avoid sharing
user/group IDs across different services that might otherwise share
them.

I'd say that the security of a container is a bit like the security of
running something in a chroot jail.  It is one additional level of
isolation that something needs to break out of.

Processes running as root inside a container (and I mean the real
root, not root in a user namespace like in my example - unless you ran
the command I gave while logged in as root) are not secure today as
far as I'm aware.  Sure, the isolation is such that a process isn't
going to accidentally escape from the container, so that is a form of
security.  However, a malicious process running as root inside a
container (or a chroot) is generally going to be able to escape if it
wants to.  Maybe some kernel hardening approaches would help with
that.

Also, a process running in a container has less info on the host,
especially if in a chroot (which is typically the case).  If you run a
shell as nobody you could probably glean quite a bit about what is
going on with the host, even if you can't directly touch most of it.
If you could run a process as nobody on many hosts maybe you could
identify which hosts you want to prioritize for further attacks.  If
they're doing the same thing on processes trapped in a
container+chroot then they're basically not going to know about any
other services on the host other than the one they've already hacked
into.

Stuff running as non-root inside a container should be very well
contained, barring kernel bugs.  As we saw a few months ago with
meltdown even running in a VM isn't a perfect guarantee of isolation.
But, I would agree that stuff running under a different UID is also
reasonably secure other than information leaks.

The main benefit of containers is isolation, IMO.  Stuff inside a
container just doesn't see anything outside, which means fewer
incompatibilities.  I run a bunch of nspawn containers mostly running
Gentoo (some with other distros inside), and the nice thing about it
is that when I update a container I know it only provides one service,
so I only have one service I need to test, vs doing a glibc update and
having to test everything.  On the other hand it is that many more
updates to do, and there is a bit more memory cost since libraries
aren't shared across them the way they would be if they all ran on the
host.

-- 
Rich

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

[R0b0t1]

On Thu, Mar 8, 2018 at 11:50 AM, Rich Freeman  wrote:
> If you have util-linux installed then try running (as any user - you
> don't have to be root):
> unshare -i -m -n -p -u -C -f --mount-proc -U -r  /bin/bash
>

Interesting. I hadn't found a good interface to containers and
clone(2) besides Docker. Of course, I didn't look very hard. I half
expect a "new" process model to develop around the kernel namespaces,
as people realize GID separation only is too coarse.

I still see some odd claims about container security, though: claiming
containers are more secure than user accounts still seems odd to me,
as if you don't trust the kernel to enforce user accounts, why trust
it to enforce namespace separation?

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

[James Le Cuirot]

On Wed, 7 Mar 2018 11:06:47 -0500
anote...@teknik.io wrote:

> Having used Gentoo for a few years now, one thing that has been annoying
> to me is the tremendous duplication of effort and uphill battle of
> creating ebuilds (build recipes) for language-specific packages that
> already have their own build systems.
> 
> For example, many languages such as Python (pip), Node (npm), Ruby
> (gems), TeXLive (tlmgr), Haskell (cabal), Rust (cargo) have ways of
> redistributing up-to-date dependencies and ensuring that they build
> properly in most environments.

I was expecting to see Java's Maven in this list. Gentoo Java is in
trouble because we have basically given up trying to keep up with the
ecosystem. The last time anything under dev-java was bumped, other than
JVMs and Tomcat-related stuff, was January 20th. We could be bumping 5
packages a day and still not keep up, never mind all the things we
haven't packaged at all yet.

Java's problem is somewhat unique in that although you can have
optional dependencies at runtime, unless you go out of your way
(and nobody ever does), all these optional dependencies are required
at build time. Suddenly a package that might normally only have 2
dependencies now has 20. But wait, that's just the first level of
dependencies! This can repeat on and on and you end up battered and
bruised having packaged 100 things but still not the one you actually
wanted.

I therefore put some thought into something along the lines of what you
have suggested. Java is supposed to be write (or really build) once,
run anywhere so why are we wasting time building things that we don't
have to? That's certainly why upstreams look at us like we're crazy
whenever we dare to contact them. If we can leverage Maven or whatever
to grab the platform-neutral dependencies for us, we can focus
attention on the few that have native libraries and also things like
icons, desktop entries, etc, that Maven doesn't deal with.

But how would this work? I thought perhaps the dependencies we don't
care about could be installed into a Maven repository, essentially
untracked by Portage but still self-contained, by fetching them in
src_unpack (or src_fetch, which I'd like to introduce) and then
installing them in pkg_preinst. However, unless src_fetch is
implemented, it would not be possible to install Java packages offline.
This approach would also break binary packages, effectively forcing
Java packages to have RESTRICT="bindist", although there would arguably
be little building to do anyway.

Apart from the fact that I haven't had time to do any of this, is this
even what Gentoo users want? I suspect not. But what's worse, this or a
totally stale or practically empty package repository?

Others have experimented with from-source ebuild generators but that
doesn't change the fact that putting all these ebuilds into the tree is
still a huge maintenance burden and because of the build time
dependency issue, end users will still have to build hundreds of
packages they don't even care about.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpui06L7uQ_G.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Proliferation of IUSE=static-libs in Gentoo

[James Le Cuirot]

On Thu, 08 Mar 2018 16:40:44 +0100
Michał Górny  wrote:

> So, developers, please *stop adding USE=static-libs* to random libraries
> that have no reason whatever to be statically linked to.

Sorry, I like a lot of your ideas but I'm with the others on this one.
I have, on the rare occasion, used these flags for various reasons.
They don't do any harm for the majority not using them. If someone does
encounter issues through using them then they are free to deal with
those themselves. Better that than not even having them available in
the first place. They are welcome to provide fixes where necessary and
maintainers are equally welcome to drop these flags as they see fit.
Such a decision should not be forced upon maintainers.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp8q2QMSbjlX.pgp
Description: OpenPGP digital signature

[gentoo-portage-dev] [PATCH] doins: don't clobber _E_INSDESTTREE_

[Mike Gilbert]

This might be set by another helper function (doconfd, doenvd, doheader).

Bug: https://bugs.gentoo.org/649946
Fixes: a5d0111d0bdaa7ee9e5c68e22b4a97ce415e119b
---
 bin/ebuild-helpers/doins | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bin/ebuild-helpers/doins b/bin/ebuild-helpers/doins
index 327d409a4..219bbe5d7 100755
--- a/bin/ebuild-helpers/doins
+++ b/bin/ebuild-helpers/doins
@@ -20,7 +20,7 @@ else
if ! ___eapi_has_DESTTREE_INSDESTTREE; then
[[ -n ${INSDESTTREE} ]] &&
die "${0##*/}: \${INSDESTTREE} has been banned for EAPI 
'$EAPI'; use 'into' instead"
-   else
+   elif [[ -z ${_E_INSDESTTREE_+set} ]]; then
# backwards compatibility
_E_INSDESTTREE_=${INSDESTTREE}
fi
-- 
2.16.2

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

[Rich Freeman]

On Thu, Mar 8, 2018 at 11:44 AM, R0b0t1  wrote:
>
> I think I was equating containers to Docker as well. My point was
> instead of trying to manage dependencies, containers allow people to
> shove everything into an empty root with no conflicts. The
> enthusiastic blog post seems to restate this.
>

That is one of many things they can do.  You can also run a service
like apache in a container even if it is installed in the same root
filesystem as all your other applications.  (In fact, I think this is
sort-of the default behavior if you start apache with the systemd unit
supplied.)

Ultimately on linux the governing functionality are kernel namespaces
and chroot (and I guess you might lump in chuid).  Kernel namespaces
involve the various types of namespaces themselves, and then the
clone/setns/unshare system calls.  There are a lot of things you can
do with various applications of these, and you don't have to run a
process in every possible separated namespace.

I mention it mainly because people tend to limit themselves by
thinking that container=docker, when linux provides a number of system
calls that administrators can employ to do useful things, and you
don't need any kind of fancy management system to use any of them, any
more than you need any fancy tools to run chroot.

If you have util-linux installed then try running (as any user - you
don't have to be root):
unshare -i -m -n -p -u -C -f --mount-proc -U -r  /bin/bash

Congrats.  You are now root in a container.  You're in the same root
filesystem as always.  You'll note that you can't actually see
anything that you couldn't see before.  If you run ps -ea you'll see
that you're the only process running on the system.  Devices like
/dev/sda aren't actually accessible.  A lot of container managers
would mount a new /dev and just hide most of that stuff.  You can
probably imagine how something like this could be useful for isolating
processes.  Try mounting a tmpfs somewhere - you'll see you can do it.
The tmpfs will be invisible to other processes though that aren't
inside the container.

-- 
Rich

[gentoo-dev] [PATCH 8/8] linux-info.eclass: Skip linux_config_*_exists on non-Linux

[Michał Górny]

The linux_config_src_exists and linux_config_bin_exists always return
false on non-Linux systems by design. Short-circuit it via
'kernel_linux' check.
---
 eclass/linux-info.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
index 554de81d3acc..8ac290979247 100644
--- a/eclass/linux-info.eclass
+++ b/eclass/linux-info.eclass
@@ -252,7 +252,7 @@ linux_config_qa_check() {
 # It returns true if .config exists in a build directory otherwise false
 linux_config_src_exists() {
export _LINUX_CONFIG_EXISTS_DONE=1
-   [[ -n ${KV_OUT_DIR} && -s ${KV_OUT_DIR}/.config ]]
+   use kernel_linux && [[ -n ${KV_OUT_DIR} && -s ${KV_OUT_DIR}/.config ]]
 }
 
 # @FUNCTION: linux_config_bin_exists
@@ -261,7 +261,7 @@ linux_config_src_exists() {
 # It returns true if .config exists in /proc, otherwise false
 linux_config_bin_exists() {
export _LINUX_CONFIG_EXISTS_DONE=1
-   [[ -s /proc/config.gz ]]
+   use kernel_linux && [[ -s /proc/config.gz ]]
 }
 
 # @FUNCTION: linux_config_exists
-- 
2.16.2

[gentoo-dev] [PATCH 7/8] linux-info.eclass: Die in most of public-ish APIs on non-Linux

[Michał Górny]

Add appropriate 'die' calls in most of the seemingly public APIs
of the eclass that could be called by ebuilds and that are going to fail
horribly when used on non-Linux systems. This means that
e.g. 'kernel_is' calls need to be explicitly guarded in ebuilds, as we
can't really reasonably return 'true' or 'false' if there is no Linux
kernel in the first place.
---
 eclass/linux-info.eclass | 36 
 1 file changed, 36 insertions(+)

diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
index 0ba7ff7755c7..554de81d3acc 100644
--- a/eclass/linux-info.eclass
+++ b/eclass/linux-info.eclass
@@ -240,6 +240,10 @@ linux_config_qa_check() {
ewarn "QA: You called $f before any linux_config_exists!"
ewarn "QA: The return value of $f will NOT guaranteed later!"
fi
+
+   if ! use kernel_linux; then
+   die "$f called on non-Linux system, please fix the ebuild"
+   fi
 }
 
 # @FUNCTION: linux_config_src_exists
@@ -290,6 +294,10 @@ linux_config_path() {
 # This function verifies that the current kernel is configured (it checks 
against the existence of .config)
 # otherwise it dies.
 require_configured_kernel() {
+   if ! use kernel_linux; then
+   die "${FUNCNAME}() called on non-Linux system, please fix the 
ebuild"
+   fi
+
if ! linux_config_src_exists; then
qeerror "Could not find a usable .config in the kernel source 
directory."
qeerror "Please ensure that ${KERNEL_DIR} points to a 
configured set of Linux sources."
@@ -369,6 +377,10 @@ linux_chkconfig_string() {
 
 # Note: duplicated in kernel-2.eclass
 kernel_is() {
+   if ! use kernel_linux; then
+   die "${FUNCNAME}() called on non-Linux system, please fix the 
ebuild"
+   fi
+
# if we haven't determined the version yet, we need to.
linux-info_get_any_version
 
@@ -439,6 +451,10 @@ get_version_warning_done=
 # KBUILD_OUTPUT (in a decreasing priority list, we look for the env var, 
makefile var or the
 # symlink /lib/modules/${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}${KV_EXTRA}/build).
 get_version() {
+   if ! use kernel_linux; then
+   die "${FUNCNAME}() called on non-Linux system, please fix the 
ebuild"
+   fi
+
local tmplocal
 
# no need to execute this twice assuming KV_FULL is populated.
@@ -592,6 +608,10 @@ get_version() {
 # It gets the version of the current running kernel and the result is the same 
as get_version() if the
 # function can find the sources.
 get_running_version() {
+   if ! use kernel_linux; then
+   die "${FUNCNAME}() called on non-Linux system, please fix the 
ebuild"
+   fi
+
KV_FULL=$(uname -r)
 
if [[ -f ${ROOT}/lib/modules/${KV_FULL}/source/Makefile && -f 
${ROOT}/lib/modules/${KV_FULL}/build/Makefile ]]; then
@@ -631,6 +651,10 @@ get_running_version() {
 # This attempts to find the version of the sources, and otherwise falls back to
 # the version of the running kernel.
 linux-info_get_any_version() {
+   if ! use kernel_linux; then
+   die "${FUNCNAME}() called on non-Linux system, please fix the 
ebuild"
+   fi
+
if ! get_version; then
ewarn "Unable to calculate Linux Kernel version for build, 
attempting to use running version"
if ! get_running_version; then
@@ -647,6 +671,10 @@ linux-info_get_any_version() {
 # @DESCRIPTION:
 # This function verifies that the current kernel sources have been already 
prepared otherwise it dies.
 check_kernel_built() {
+   if ! use kernel_linux; then
+   die "${FUNCNAME}() called on non-Linux system, please fix the 
ebuild"
+   fi
+
# if we haven't determined the version yet, we need to
require_configured_kernel
 
@@ -676,6 +704,10 @@ check_kernel_built() {
 # @DESCRIPTION:
 # This function verifies that the current kernel support modules (it checks 
CONFIG_MODULES=y) otherwise it dies.
 check_modules_supported() {
+   if ! use kernel_linux; then
+   die "${FUNCNAME}() called on non-Linux system, please fix the 
ebuild"
+   fi
+
# if we haven't determined the version yet, we need too.
require_configured_kernel
 
@@ -832,6 +864,10 @@ check_extra_config() {
 }
 
 check_zlibinflate() {
+   if ! use kernel_linux; then
+   die "${FUNCNAME}() called on non-Linux system, please fix the 
ebuild"
+   fi
+
# if we haven't determined the version yet, we need to
require_configured_kernel
 
-- 
2.16.2

[gentoo-dev] [PATCH 6/8] linux-info.eclass: Ignore check_extra_config on non-Linux

[Michał Górny]

Make the check_extra_config and pkg_setup calls no-op on non-Linux
systems. Those systems don't have a Linux kernel, so they obviously
can't satisfy the requirements. This currently results in a lot of
useless warnings about missing Linux kernel sources on FreeBSD. We could
make it conditional per-package but there is really no point in adding
a lot of conditionals everywhere if this eclass can't ever work
on non-Linux.
---
 eclass/linux-info.eclass | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
index 5ffaf3f3b898..0ba7ff7755c7 100644
--- a/eclass/linux-info.eclass
+++ b/eclass/linux-info.eclass
@@ -110,6 +110,8 @@ inherit toolchain-funcs versionator
 
 EXPORT_FUNCTIONS pkg_setup
 
+IUSE="kernel_linux"
+
 # Overwritable environment Var's
 # ---
 KERNEL_DIR="${KERNEL_DIR:-${ROOT}usr/src/linux}"
@@ -688,8 +690,10 @@ check_modules_supported() {
 # @FUNCTION: check_extra_config
 # @DESCRIPTION:
 # It checks the kernel config options specified by CONFIG_CHECK. It dies only 
when a required config option (i.e.
-# the prefix ~ is not used) doesn't satisfy the directive.
+# the prefix ~ is not used) doesn't satisfy the directive. Ignored on 
non-Linux systems.
 check_extra_config() {
+   use kernel_linux || return
+
local config negate die error reworkmodulenames
local soft_errors_count=0 hard_errors_count=0 config_required=0
# store the value of the QA check, because otherwise we won't catch 
usages
@@ -902,6 +906,8 @@ check_zlibinflate() {
 # Force a get_version() call when inherited from linux-mod.eclass and then 
check if the kernel is configured
 # to support the options specified in CONFIG_CHECK (if not null)
 linux-info_pkg_setup() {
+   use kernel_linux || return
+
linux-info_get_any_version
 
if kernel_is 2 4; then
-- 
2.16.2

[gentoo-dev] [PATCH 5/8] linux-info.eclass: require_configured_kernel, improve error handling

[Michał Górny]

Add error handling for failing get_version call
in require_configured_kernel. Give just a simple 'die' message since
the get_version function should verbosely explain the problem.
---
 eclass/linux-info.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
index 177cb7fafcde..5ffaf3f3b898 100644
--- a/eclass/linux-info.eclass
+++ b/eclass/linux-info.eclass
@@ -295,7 +295,7 @@ require_configured_kernel() {
qeerror "it points to the necessary object directory so that it 
might find .config."
die "Kernel not configured; no .config found in ${KV_OUT_DIR}"
fi
-   get_version
+   get_version || die "Unable to determine configured kernel version"
 }
 
 # @FUNCTION: linux_chkconfig_present
-- 
2.16.2

[gentoo-dev] [PATCH 4/8] linux-info.eclass: Move get_version to require_configured_kernel

[Michał Górny]

All require_configured_kernel calls in this eclass are followed
by a get_version call. Since even calling it proactively wouldn't hurt,
move it to require_configured_kernel. This saves us from having
to manually implement error handling for it everywhere.
---
 eclass/linux-info.eclass | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
index 37a60b430646..177cb7fafcde 100644
--- a/eclass/linux-info.eclass
+++ b/eclass/linux-info.eclass
@@ -295,6 +295,7 @@ require_configured_kernel() {
qeerror "it points to the necessary object directory so that it 
might find .config."
die "Kernel not configured; no .config found in ${KV_OUT_DIR}"
fi
+   get_version
 }
 
 # @FUNCTION: linux_chkconfig_present
@@ -646,7 +647,6 @@ linux-info_get_any_version() {
 check_kernel_built() {
# if we haven't determined the version yet, we need to
require_configured_kernel
-   get_version
 
local versionh_path
if kernel_is -ge 3 7; then
@@ -676,7 +676,6 @@ check_kernel_built() {
 check_modules_supported() {
# if we haven't determined the version yet, we need too.
require_configured_kernel
-   get_version
 
if ! linux_chkconfig_builtin "MODULES"; then
eerror "These sources do not support loading external modules."
@@ -831,7 +830,6 @@ check_extra_config() {
 check_zlibinflate() {
# if we haven't determined the version yet, we need to
require_configured_kernel
-   get_version
 
# although I restructured this code - I really really really dont 
support it!
 
-- 
2.16.2

[gentoo-dev] [PATCH 3/8] linux-info.eclass: linux-info_get_any_version, die on failure

[Michał Górny]

Make linux-info_get_any_version die if it can't determine any version
of the Linux kernel. This indicates a problem with the eclass code
(as it should not happen on Linux) and the missing KV_* variables
are going to cause random misbehavior and failures.
---
 eclass/linux-info.eclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
index df6227220b79..37a60b430646 100644
--- a/eclass/linux-info.eclass
+++ b/eclass/linux-info.eclass
@@ -630,7 +630,9 @@ get_running_version() {
 linux-info_get_any_version() {
if ! get_version; then
ewarn "Unable to calculate Linux Kernel version for build, 
attempting to use running version"
-   get_running_version
+   if ! get_running_version; then
+   die "Unable to determine any Linux Kernel version, 
please report a bug"
+   fi
fi
 }
 
-- 
2.16.2

[gentoo-dev] [PATCH 2/8] linux-info.eclass: Replace unnecessary $? checks

[Michał Górny]

---
 eclass/linux-info.eclass | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
index b8c1a524bae8..df6227220b79 100644
--- a/eclass/linux-info.eclass
+++ b/eclass/linux-info.eclass
@@ -628,8 +628,7 @@ get_running_version() {
 # This attempts to find the version of the sources, and otherwise falls back to
 # the version of the running kernel.
 linux-info_get_any_version() {
-   get_version
-   if [[ $? -ne 0 ]]; then
+   if ! get_version; then
ewarn "Unable to calculate Linux Kernel version for build, 
attempting to use running version"
get_running_version
fi
@@ -848,13 +847,11 @@ check_zlibinflate() {
 
ebegin "checking ZLIB_INFLATE"
linux_chkconfig_builtin CONFIG_ZLIB_INFLATE
-   eend $?
-   [ "$?" != 0 ] && die
+   eend $? || die
 
ebegin "checking ZLIB_DEFLATE"
linux_chkconfig_builtin CONFIG_ZLIB_DEFLATE
-   eend $?
-   [ "$?" != 0 ] && die
+   eend $? || die
 
local LINENO_START
local LINENO_END
-- 
2.16.2

[gentoo-dev] [PATCH 1/8] linux-info.eclass: get_localversion, do not call 'ls'

[Michał Górny]

Use bash array to perform a safe filename glob instead of calling 'ls'.
Also, use nullglob to cleanly handle no matches instead of silencing
errors.
---
 eclass/linux-info.eclass | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass
index 035b722e2d6d..b8c1a524bae8 100644
--- a/eclass/linux-info.eclass
+++ b/eclass/linux-info.eclass
@@ -390,8 +390,13 @@ kernel_is() {
 get_localversion() {
local lv_list i x
 
+   local shopt_save=$(shopt -p nullglob)
+   shopt -s nullglob
+   local files=( ${1}/localversion* )
+   ${shopt_save}
+
# ignore files with ~ in it.
-   for i in $(ls ${1}/localversion* 2>/dev/null); do
+   for i in "${files[@]}"; do
[[ -n ${i//*~*} ]] && lv_list="${lv_list} ${i}"
done
 
-- 
2.16.2

[gentoo-dev] [PATCH 0/8] linux-info.eclass: cleanup & better non-Linux support

[Michał Górny]

Hi, everyone.

Here's a patch set for linux-info.eclass. Besides some minor cleanup,
it improves error handling and adds explicit handling for non-Linux
systems.

Currently, the eclass pretty much wrongly assumes that every system
is Linux. This causes e.g. a lot of spurious warnings or completely
random behavior on FreeBSD. While we could technically solve it
by adding appropriate conditionals to ebuilds, it seems pointless
to have to add it everywhere if the eclass can never be useful
for non-Linux targets.

For the purpose of these patches, I've split the public-ish API
of the eclass into three groups:

a. check_extra_config & pkg_setup are commonly used in 'assert'-style
   with non-fatal results. Those functions are made no-ops on non-Linux
   systems.

b. Some functions are fatal assert-style, i.e. die if kernel doesn't
   support X. Those now die explicitly on non-Linux systems (as they
   would probably anyway).

c. Functions that provide true/false results and get version can't work
   correctly on FreeBSD, and the failure can't be cleanly expressed
   in true/false (think of kernel_is). Those functions now also die
   on non-Linux systems and needs to be guarded in ebuilds.

Please review.

--
Best regards,
Michał Górny

Michał Górny (8):
  linux-info.eclass: get_localversion, do not call 'ls'
  linux-info.eclass: Replace unnecessary $? checks
  linux-info.eclass: linux-info_get_any_version, die on failure
  linux-info.eclass: Move get_version to require_configured_kernel
  linux-info.eclass: require_configured_kernel, improve error handling
  linux-info.eclass: Ignore check_extra_config on non-Linux
  linux-info.eclass: Die in most of public-ish APIs on non-Linux
  linux-info.eclass: Skip linux_config_*_exists on non-Linux

 eclass/linux-info.eclass | 72 ++--
 1 file changed, 58 insertions(+), 14 deletions(-)

-- 
2.16.2

Re: [gentoo-dev] Proliferation of IUSE=static-libs in Gentoo

[Jeroen Roovers]

On Thu, 08 Mar 2018 16:40:44 +0100
Michał Górny  wrote:

> As part of that we also shouldn't deliver static libraries

OK, so you want to absolutely kill dead the only current sane way for
developers who use Gentoo to ship static binaries to their users'
target systems? Drive them away to another Linux distro that does
support being the build platform that they need? Or force everyone to
use EXTRA_ECONF"--enable-static" and hope for them that it works for
all packages? All just because static linking *between* ebuilds is bad?

> So, developers, please *stop adding USE=static-libs* to random
> libraries that have no reason whatever to be statically linked to.

You could just as well work on stopping the package manager from linking
to static libraries instead and leave other developers to add
IUSE=static-libs as they please, so that no one has to worry about
static linking of packages that we do support in the package manager.

Please rethink your stated opinion thoroughly.

Also, please drop "random" from every odd sentence you post - it makes
your target audience feel like they're idiots who "didn't get it".

Also, please stop marketing your opinions as set in stone policy -
you're here to discuss things and develop policy, but your condescending
and authoritarian tone isn't helping the argument.


Kind regards,
 jer

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

[R0b0t1]

On Wed, Mar 7, 2018 at 3:06 PM, Rich Freeman  wrote:
> On Wed, Mar 7, 2018 at 3:55 PM, R0b0t1  wrote:
>> On Wed, Mar 7, 2018 at 1:15 PM, Alec Warner  wrote:
>>>
>>> Because containers are awesome and are way easier to use.
>>>
>>
>> I think you missed my point: Why are they easier to use?
>>
>
> I suspect that he was equating "containers" with "Docker," which both
> runs containers and also is an image management solution (one that I
> don't particularly like, but probably because I don't have heavy needs
> so I find myself fighting it more than anything else - it doesn't hurt
> that for the life of me I can't get it to connect containers to my
> bridge, and it seems like it is completely opposed to just using DHCP
> to obtain IPs).
>
> But, if you're using Docker, sure, you can run whatever the command is
> to download an image of a container with some software pre-installed
> and run it.
>
> If you're using something other than Docker to manage your containers
> then you still have to get the software you want to use installed in
> your container image.
>

I think I was equating containers to Docker as well. My point was
instead of trying to manage dependencies, containers allow people to
shove everything into an empty root with no conflicts. The
enthusiastic blog post seems to restate this.

Re: [gentoo-dev] Proliferation of IUSE=static-libs in Gentoo

[Rich Freeman]

On Thu, Mar 8, 2018 at 10:40 AM, Michał Górny  wrote:
>
> So, developers, please *stop adding USE=static-libs* to random libraries
> that have no reason whatever to be statically linked to. And by that I
> mean a good reason, not creeping featurism, not 'user asked for it', not
> 'this broken package hardcodes libfoo.a'.
>

While I agree with all the arguments against using static libs, this
seems a bit contrary to the spirit of Gentoo.  Certainly building
static libs shouldn't be the default.  However, if for some reason a
user feels they need static libs, do we really need to make them jump
through a million hoops simply because maybe we wouldn't do the same
thing in their shoes?

Why not just let maintainers add support if they wish, and neither
require them to do so nor prohibit or discourage them?

Now, if a package requires static linking that should be considered a
bug, except where it really does make sense (bootloaders, kernels,
firmware, etc).  If a package installs static libs by default this
should generally also be a bug.

IMO this is not a feature that causes harm simply by being available.
It isn't like a dialog box that has 500 boxes to hunt through.  This
is a global use flag that everybody understands, and which defaults to
off.  Keep in mind also that a lot of people use Gentoo in weird
niches, and flexibility is our main selling point.  Our users
shouldn't have to beg to have use cases supported if it is easy to
support them, just because their use cases are rare.  If we excluded
all rare use cases from Gentoo we'd probably exclude just about all of
them in practice, because if somebody just wanted Ubuntu or CentOS or
Debian they'd be using Ubuntu or CentOS or Debian.

Just my own two cents here.

-- 
Rich

Re: [gentoo-dev] Proliferation of IUSE=static-libs in Gentoo

[Alec Warner]

On Thu, Mar 8, 2018 at 10:40 AM, Michał Górny  wrote:

> Hello, developers.
>
> I would like to bring to your attention an alarming trend in Gentoo
> ebuilds -- the proliferation of IUSE=static-libs, that is a flag
> allowing our users to build static libraries.
>
> I should like to remind you that static linking is almost always a bad
> idea. It has serious security implications, it is poorly supported on
> *nix systems (example: library dependencies are provided via hacks, we
> don't have proper rebuild capabilities) and should be basically
> considered  a great evil. Partially relevant doc: [1].
>
> This is why Gentoo does not generally support statically linking stuff,
> and we force dynamic linking whenever possible (sometimes even going too
> far with that but that's another story). We only allow static linking
> for special cases where shared linking can't be used for one reason
> or another.
>

> As part of that we also shouldn't deliver static libraries unless
> absolutely necessary to satisfy the dependencies of applications which
> we support built statically. Back in the day, Gentoo developers were
> pushing against packages that built static libraries unconditionally.
> However, it seems that at some point this front changed from 'fighting
> unconditionally built static libraries' to 'proliferating USE=static-
> libs everywhere'. Which is bad.
>
>
So to me this is a murky metadistribution / distribution problem.

Like if upstream ships "--enable-static-libs" we should probably support a
USE flag to enable it; this is the metadistribution use case.[1]

For people actually running Gentoo, Gentoo strongly advises not building
static libs (and we can disable the static-libs USE flag in a profile or
otherwise
encourage users not to use it because of all the reasons stated.)

So, developers, please *stop adding USE=static-libs* to random libraries
> that have no reason whatever to be statically linked to. And by that I
> mean a good reason, not creeping featurism, not 'user asked for it', not
> 'this broken package hardcodes libfoo.a'.
>
> If upstream doesn't build static libraries by default, don't add flags
> to make it do it. If upstream builds static libraries by default, just
> pass '--disable-static' instead of adding a flag for it. If upstream
> uses CMake and supports building only one type of libraries, there's no
> need to write patches to make it behave like automake/libtool.
>
> Also, if your package has unnecessary IUSE=static-libs that is not
> correctly needed by any other package, please drop it.
>
> Please remember that not installing static libraries is the first step
> towards preventing broken build systems from unnecessary linking to them
> (think of upstreams who pass -Wl,-Bstatic unconditionally).
>

[1] I am somewhat empathetic to the argument that when we support something
in the metadistribution but no distributions are using it; it can become
stale / broken / untested
and I'd consider not adding the flags on those grounds though.


>
> Thanks.
>
> [1]:https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies
>
> --
> Best regards,
> Michał Górny
>
>
>

[gentoo-dev] Proliferation of IUSE=static-libs in Gentoo

[Michał Górny]

Hello, developers.

I would like to bring to your attention an alarming trend in Gentoo
ebuilds -- the proliferation of IUSE=static-libs, that is a flag
allowing our users to build static libraries.

I should like to remind you that static linking is almost always a bad
idea. It has serious security implications, it is poorly supported on
*nix systems (example: library dependencies are provided via hacks, we
don't have proper rebuild capabilities) and should be basically
considered  a great evil. Partially relevant doc: [1].

This is why Gentoo does not generally support statically linking stuff,
and we force dynamic linking whenever possible (sometimes even going too
far with that but that's another story). We only allow static linking
for special cases where shared linking can't be used for one reason
or another.

As part of that we also shouldn't deliver static libraries unless
absolutely necessary to satisfy the dependencies of applications which
we support built statically. Back in the day, Gentoo developers were
pushing against packages that built static libraries unconditionally.
However, it seems that at some point this front changed from 'fighting
unconditionally built static libraries' to 'proliferating USE=static-
libs everywhere'. Which is bad.

So, developers, please *stop adding USE=static-libs* to random libraries
that have no reason whatever to be statically linked to. And by that I
mean a good reason, not creeping featurism, not 'user asked for it', not
'this broken package hardcodes libfoo.a'.

If upstream doesn't build static libraries by default, don't add flags
to make it do it. If upstream builds static libraries by default, just
pass '--disable-static' instead of adding a flag for it. If upstream
uses CMake and supports building only one type of libraries, there's no
need to write patches to make it behave like automake/libtool.

Also, if your package has unnecessary IUSE=static-libs that is not
correctly needed by any other package, please drop it.

Please remember that not installing static libraries is the first step
towards preventing broken build systems from unnecessary linking to them
(think of upstreams who pass -Wl,-Bstatic unconditionally).

Thanks.

[1]:https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies

-- 
Best regards,
Michał Górny

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

[kuzetsa]

On 03/07/2018 11:06 AM, anote...@teknik.io wrote:

> It seems reasonable to me to 'hook' portage into these
> other package managers, so that running 'emerge bar'
> would actually run 'cabal install bar' rather than
> downloading sources and running 'ghc'.

it gets tricky when there's no good way to even fetch
the source, I mean. Sorry about not proofreading:

On 03/08/2018 09:47 AM, kuzetsa wrote:
> dependencies which can't otherwise be satisfied is the
> point of the original poster / creator of this thread:

I'm certain I worded that wrong. My intent had been to
say that a point which //was not addressed by// the OP

(oops)



signature.asc
Description: OpenPGP digital signature

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

[kuzetsa]

On 03/08/2018 07:25 AM, Michael Orlitzky wrote:
> On 03/08/2018 12:54 AM, Benda Xu wrote:
>>
>> This title itself is amusing enough
>>
>>   Motherfuckers need package management
>>
> 
> Which if it is not clear, is intended to be funny.
> 
> 

the colorful language was proportional to the enthusiasm.

decent info, even though the excited person who wrote it
made me roll my eyes (I clicked for the info ::shrug::)

as per this thread: NuGET (mentioned in the article) is
something I had briefly considered trying to hook into:

an upstream decided that one of their own libraries (it
was written / maintained by upstream) should be unbundled
rather than vendored, but instead of giving it standalone
packaging, they decided to make it only available via
NuGET. Since I had never used .NET before, I had no idea
what that even was, initially. It was a "an experience".

dependencies which can't otherwise be satisfied is the
point of the original poster / creator of this thread:

On 03/07/2018 11:06 AM, anote...@teknik.io wrote:

> Is this a feature/improvement other Gentoo users/developers
> would be interested in? If so, I would love to help discuss
> and potentially help with its implementation.
>

The problem with something like NuGET, is that I don't
know how to safely support the package manager itself.

I think it's a terrible idea to let "something like that"
loose on a gentoo system...

https://docs.microsoft.com/en-us/visualstudio/mac/nuget-walkthrough

^ I guess they officially support mac, but still.
what happens when the developer of a package manager
decide they need root access to your system, but then
do things "their way"? I've got some concerns.



signature.asc
Description: OpenPGP digital signature

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

[Michael Orlitzky]

On 03/08/2018 12:54 AM, Benda Xu wrote:
> 
> This title itself is amusing enough
> 
>   Motherfuckers need package management
> 

Which if it is not clear, is intended to be funny.