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

[gentoo-dev] last rites: dev-perl/Gtk2-WebKit

[Andreas K. Huettel]

# Andreas K. Hüttel  (21 May 2016)
# Unmaintained since 2011, needs old webkit-gtk:2 slot that has
# security issues, no consumers in tree, bug 573092
# Removal in 30 days
dev-perl/Gtk2-WebKit

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

[gentoo-dev] [PATCH 2/2] Add tests for rebar.eclass

[aidecoe]

From: Amadeusz Żołnowski 

---
 eclass/tests/rebar_fix_include_path.sh | 159 +
 eclass/tests/rebar_remove_deps.sh  |  99 
 eclass/tests/rebar_set_vsn.sh  | 115 
 3 files changed, 373 insertions(+)
 create mode 100755 eclass/tests/rebar_fix_include_path.sh
 create mode 100755 eclass/tests/rebar_remove_deps.sh
 create mode 100755 eclass/tests/rebar_set_vsn.sh

diff --git a/eclass/tests/rebar_fix_include_path.sh 
b/eclass/tests/rebar_fix_include_path.sh
new file mode 100755
index 000..9047f8d
--- /dev/null
+++ b/eclass/tests/rebar_fix_include_path.sh
@@ -0,0 +1,159 @@
+#!/bin/bash
+# Copyright 1999-2016 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Id$
+
+source tests-common.sh
+
+EAPI=6
+
+inherit rebar
+
+EPREFIX="${tmpdir}/fakeroot"
+S="${WORKDIR}/${P}"
+
+setup() {
+   mkdir -p "${S}" || die
+
+   for pkg in foo-0.1.0 bar-0.1.0; do
+   mkdir -p "${EPREFIX}$(get_erl_libs)/${pkg}/include" || die
+   done
+
+   cat <"${S}/typical.config" || die
+%%% Comment
+
+{erl_opts, [debug_info, {src_dirs, ["src"]},
+   {i, "include"},
+   {i, "deps/foo/include"},
+   {i, "../foo/include"}]}.
+
+{port_env, [{"CFLAGS", "\$CFLAGS"}, {"LDFLAGS", "\$LDFLAGS"}]}.
+EOF
+
+   cat <"${S}/typical.config.expected" || die
+%%% Comment
+
+{erl_opts, [debug_info, {src_dirs, ["src"]},
+   {i, "include"},
+   {i, "${EPREFIX}$(get_erl_libs)/foo-0.1.0/include"},
+   {i, "../foo/include"}]}.
+
+{port_env, [{"CFLAGS", "\$CFLAGS"}, {"LDFLAGS", "\$LDFLAGS"}]}.
+EOF
+
+   cat <"${S}/inc_one_line.config" || die
+%%% Comment
+
+{erl_opts, [debug_info, {src_dirs, ["src"]}, {i, "include"}, {i, 
"deps/foo/include"}, {i, "../foo/include"}]}.
+
+{port_env, [{"CFLAGS", "\$CFLAGS"}, {"LDFLAGS", "\$LDFLAGS"}]}.
+EOF
+
+   cat <"${S}/inc_one_line.config.expected" || die
+%%% Comment
+
+{erl_opts, [debug_info, {src_dirs, ["src"]}, {i, "include"}, {i, 
"${EPREFIX}$(get_erl_libs)/foo-0.1.0/include"}, {i, "../foo/include"}]}.
+
+{port_env, [{"CFLAGS", "\$CFLAGS"}, {"LDFLAGS", "\$LDFLAGS"}]}.
+EOF
+}
+
+test_typical_config() {
+   local diff_rc
+   local unit_rc
+
+   # Prepare
+   cd "${S}" || die
+   cp typical.config rebar.config || die
+
+   # Run unit
+   (rebar_fix_include_path foo)
+   unit_rc=$?
+
+   # Test result
+   diff rebar.config typical.config.expected
+   diff_rc=$?
+
+   [[ ${unit_rc}${diff_rc} = 00 ]]
+}
+
+test_multiple_versions() {
+   local diff_rc
+   local unit_rc
+
+   # Prepare
+   cd "${S}" || die
+   cp typical.config rebar.config || die
+   mkdir -p "${EPREFIX}$(get_erl_libs)/foo-1.0.0/include" || die
+
+   # Run unit
+   (rebar_fix_include_path foo 2>/dev/null)
+   unit_rc=$?
+
+   # Test result
+   diff rebar.config typical.config
+   diff_rc=$?
+
+   # Clean up
+   rm -r "${EPREFIX}$(get_erl_libs)/foo-1.0.0" || die
+
+   [[ ${unit_rc}${diff_rc} = 10 ]]
+}
+
+test_not_found() {
+   local diff_rc
+   local unit_rc
+
+   # Prepare
+   cd "${S}" || die
+   cp typical.config rebar.config || die
+
+   # Run unit
+   (rebar_fix_include_path fo 2>/dev/null)
+   unit_rc=$?
+
+   # Test result
+   diff rebar.config typical.config
+   diff_rc=$?
+
+   [[ ${unit_rc}${diff_rc} = 10 ]]
+}
+
+test_includes_in_one_line() {
+   local diff_rc
+   local unit_rc
+
+   # Prepare
+   cd "${S}" || die
+   cp inc_one_line.config rebar.config || die
+
+   # Run unit
+   (rebar_fix_include_path foo)
+   unit_rc=$?
+
+   # Test result
+   diff rebar.config inc_one_line.config.expected
+   diff_rc=$?
+
+   [[ ${unit_rc}${diff_rc} = 00 ]]
+}
+
+setup
+
+tbegin "rebar_fix_include_path deals with typical config"
+test_typical_config
+tend $?
+
+tbegin "rebar_fix_include_path fails on multiple versions of dependency"
+test_multiple_versions
+tend $?
+
+tbegin "rebar_fix_include_path fails if dependency is not found"
+test_not_found
+tend $?
+
+tbegin "rebar_fix_include_path deals with all includes in one line"
+test_includes_in_one_line
+tend $?
+
+texit
diff --git a/eclass/tests/rebar_remove_deps.sh 
b/eclass/tests/rebar_remove_deps.sh
new file mode 100755
index 000..05207a7
--- /dev/null
+++ b/eclass/tests/rebar_remove_deps.sh
@@ -0,0 +1,99 @@
+#!/bin/bash
+# Copyright 1999-2016 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Id$
+
+source tests-common.sh
+
+EAPI=6
+
+inherit rebar
+
+EPREFIX="${tmpdir}/fakeroot"
+S="${WORKDIR}/${P}"
+
+setup() {
+   mkdir -p "${S}" || die
+
+   cat <"${S}/rebar.config.expected" || die
+%%% Comment
+
+{port_specs, [{"priv/lib/esip_drv.so", 

Re: [gentoo-dev] [PATCH] distutils-r1.eclass: Do not modify the HOME variable

[Matthew Thode]

On 05/06/2016 08:25 AM, Mike Gilbert wrote:
> This was only necessary when we ran phases in parallel.
> Also, PMS says this variable should not be modified.
> ---
>  eclass/distutils-r1.eclass | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
> index 7965e91..497bed5 100644
> --- a/eclass/distutils-r1.eclass
> +++ b/eclass/distutils-r1.eclass
> @@ -628,12 +628,6 @@ distutils-r1_run_phase() {
>   # in the sys.path_importer_cache)
>   mkdir -p "${BUILD_DIR}/lib" || die
>  
> - # We need separate home for each implementation, for .pydistutils.cfg.
> - if [[ ! ${DISTUTILS_SINGLE_IMPL} ]]; then
> - local -x HOME=${HOME}/${EPYTHON}
> - mkdir -p "${HOME}" || die
> - fi
> -
>   # Set up build environment, bug #513664.
>   local -x AR=${AR} CC=${CC} CPP=${CPP} CXX=${CXX}
>   tc-export AR CC CPP CXX
> 

Thanks for this, think I reported it a while ago, can't find the bug though.

-- 
-- Matthew Thode (prometheanfire)

[gentoo-dev] [PATCH] rebar.eclass: Build Erlang/OTP projects using dev-util/rebar

[aidecoe]

From: Amadeusz Żołnowski 

It is an eclass providing functions to build Erlang/OTP projects using
dev-util/rebar. All packages in upcoming category dev-erlang are going
to use this eclass.
---
 eclass/rebar.eclass | 223 
 1 file changed, 223 insertions(+)
 create mode 100644 eclass/rebar.eclass

diff --git a/eclass/rebar.eclass b/eclass/rebar.eclass
new file mode 100644
index 000..1a4eaba
--- /dev/null
+++ b/eclass/rebar.eclass
@@ -0,0 +1,223 @@
+# Copyright 1999-2016 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Id$
+
+# @ECLASS: rebar.eclass
+# @MAINTAINER:
+# Amadeusz Żołnowski 
+# @AUTHOR:
+# Amadeusz Żołnowski 
+# @BLURB: Build Erlang/OTP projects using dev-util/rebar.
+# @DESCRIPTION:
+# An eclass providing functions to build Erlang/OTP projects using
+# dev-util/rebar.
+#
+# rebar is a tool which tries to resolve dependencies itself which is by
+# cloning remote git repositories. Dependant projects are usually expected to
+# be in sub-directory 'deps' rather than looking at system Erlang lib
+# directory. Projects relying on rebar usually don't have 'install' make
+# targets. The eclass workarounds some of these problems. It handles
+# installation in a generic way for Erlang/OTP structured projects.
+
+case "${EAPI:-0}" in
+   0|1|2|3|4|5)
+   die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
+   ;;
+   6)
+   ;;
+   *)
+   die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
+   ;;
+esac
+
+EXPORT_FUNCTIONS src_prepare src_compile src_install
+
+RDEPEND="dev-lang/erlang"
+DEPEND="${RDEPEND}
+   dev-util/rebar
+   >=sys-apps/gawk-4.1"
+
+# @ECLASS-VARIABLE: REBAR_APP_SRC
+# @DESCRIPTION:
+# Relative path to .app.src description file.
+REBAR_APP_SRC="${REBAR_APP_SRC-src/${PN}.app.src}"
+
+# @FUNCTION: get_erl_libs
+# @RETURN: the path to Erlang lib directory
+# @DESCRIPTION:
+# Get the full path without EPREFIX to Erlang lib directory.
+get_erl_libs() {
+   echo "/usr/$(get_libdir)/erlang/lib"
+}
+
+# @FUNCTION: _rebar_find_dep
+# @INTERNAL
+# @USAGE: 
+# @RETURN: full path with EPREFIX to a Erlang package/project on success,
+# code 1 when dependency is not found and code 2 if multiple versions of
+# dependency are found.
+# @DESCRIPTION:
+# Find a Erlang package/project by name in Erlang lib directory. Project
+# directory is usually suffixed with version. It is matched to ''
+# or '-*'.
+_rebar_find_dep() {
+   local pn="$1"
+   local p
+   local result
+
+   pushd "${EPREFIX}$(get_erl_libs)" >/dev/null || return 1
+   for p in ${pn} ${pn}-*; do
+   if [[ -d ${p} ]]; then
+   # Ensure there's at most one matching.
+   [[ ${result} ]] && return 2
+   result="${p}"
+   fi
+   done
+   popd >/dev/null || die
+
+   [[ ${result} ]] || return 1
+   echo "${result}"
+}
+
+# @FUNCTION: erebar
+# @USAGE: 
+# @DESCRIPTION:
+# Run rebar with verbose flag. Die on failure.
+erebar() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   (( $# > 0 )) || die "erebar: at least one target is required"
+
+   local -x ERL_LIBS="${EPREFIX}$(get_erl_libs)"
+   rebar -v skip_deps=true "$@" || die "rebar $@ failed"
+}
+
+# @FUNCTION: rebar_fix_include_path
+# @USAGE: 
+# @DESCRIPTION:
+# Fix path in rebar.config to 'include' directory of dependant project/package,
+# so it points to installation in system Erlang lib rather than relative 'deps'
+# directory.
+#
+# The function dies on failure.
+rebar_fix_include_path() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local pn="$1"
+   local erl_libs="${EPREFIX}$(get_erl_libs)"
+   local p
+
+   p="$(_rebar_find_dep "${pn}")" \
+   || die "failed to unambiguously resolve dependency of '${pn}'"
+
+   gawk -i inplace \
+   -v erl_libs="${erl_libs}" -v pn="${pn}" -v p="${p}" '
+/^{[[:space:]]*erl_opts[[:space:]]*,/, /}[[:space:]]*\.$/ {
+   pattern = "\"(./)?deps/" pn "/include\"";
+   if (match($0, "{i,[[:space:]]*" pattern "[[:space:]]*}")) {
+   sub(pattern, "\"" erl_libs "/" p "/include\"");
+   }
+   print $0;
+   next;
+}
+1
+' rebar.config || die "failed to fix include paths in rebar.config for '${pn}'"
+}
+
+# @FUNCTION: rebar_remove_deps
+# @DESCRIPTION:
+# Remove dependencies list from rebar.config and deceive build rules that any
+# dependencies are already fetched and built. Otherwise rebar tries to fetch
+# dependencies and compile them.
+#
+# The function dies on failure.
+rebar_remove_deps() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   mkdir -p "${S}/deps" && :>"${S}/deps/.got" && :>"${S}/deps/.built" || 
die
+   gawk -i inplace '
+/^{[[:space:]]*deps[[:space:]]*,/, 

Re: [gentoo-portage-dev] [PATCH v2 2/2] portage.package.ebuild.config: Always export filtered USE_EXPAND vars

[Zac Medico]

On 05/21/2016 12:15 AM, Michał Górny wrote:
> Ensure that all USE_EXPAND variables are always exported with filtered
> USE flags inside, even if none of those flags are declared in IUSE.
> This is the behavior required for EAPI 5+ by the PMS.
> 
> Since the behavior for earlier EAPIs is left undefined and having
> different behavior would be confusing to users, apply it in earlier
> EAPIs as well.

The patch looks correct. However, I think it's arguable that the
existing portage behavior makes more sense that what PMS dictates,
because why should USE_EXPAND have any effect on a package which doesn't
declare the corresponding flags in IUSE?

Anyway, given the invasive nature of the proposed change, it's probably
a good idea to have the council weigh in on this.
-- 
Thanks,
Zac

Re: [gentoo-dev] [PATCH] rebar.eclass: Build Erlang/OTP projects using dev-util/rebar

[Amadeusz Żołnowski]

Michał Górny  writes:
>> +# Run rebar with verbose flag. Die on failure.
>> +erebar() {
>> +debug-print-function ${FUNCNAME} "${@}"
>> +
>> +(( $# > 0 )) || die 'erebar: at least one target is required'
>
> Why not [[ $# -gt 0 ]]? It's the first time I see someone using (( ))
> for conditionals.

'>' reads better than some '-gt'.


>> +evar_push ERL_LIBS
>> +export ERL_LIBS="${EPREFIX}$(get_erl_libs)"
>
> local -x ERL_LIBS=...
>
> We don't really have to employ terribly ugly eval hackery to have
> a local variable.

Fixed. I hoped there's better way! (-:


> I meant indent like this:
>
> + eawk rebar.config \
> + -v erl_libs="${erl_libs}" -v pn="${pn}" -v pv="${pv}" \
> + '/^{[[:space:]]*erl_opts[[:space:]]*,/, /}[[:space:]]*\.$/ {
> + pattern = "\"(./)?deps/" pn "/include\"";
> + if (match($0, "{i,[[:space:]]*" pattern 
> "[[:space:]]*}")) {
> + sub(pattern, "\"" erl_libs "/" pn "-" pv 
> "/include\"");
> + }
> + print $0;
> + next;
> + }
> + 1
> + ' || die "failed to fix include paths in rebar.config"

OK.


>> +insinto "${dest}"
>> +doins -r ebin
>> +[[ -d include ]] && doins -r include
>> +[[ -d bin ]] && for bin in bin/*; do dobin "$bin"; done
>> +[[ -d priv ]] && cp -pR priv "${ED}${dest}/"
>
> Missing ||die. Just don't do it as one-liner :-P.

You've got me! ;-)


Thanks,
-- 
Amadeusz Żołnowski


signature.asc
Description: PGP signature

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

[Amadeusz Żołnowski]

Michał Górny  writes:>
>> +# Following commands should always succeed unless something weird is 
>> going
>> +# on.
>> +cat "${tmpf}" >"${f}" || die 'failed to replace source file' || return
>> +rm "${tmpf}" || die "failed to remove temporary file"
>
> Any reason not to use mv here? Aside to making this simpler, it would
> also prevent this from rewriting contents of hardlinked files.

Permissions of ${f} wouldn't be preserved.

>> +return 1
>> +}
>> +
>> +tbegin "preserves permissions"
>> +
>> +cd "${tmpdir}" || tend $?
>
> This doesn't terminate tests. So you'll end up creating files
> in the wrong directory.

Of course! :-/ Probably it would be best to put each test case in a
function. I have the same issue in tests for rebar.eclass. Thanks!

PS. As of discussion with robbat2, I am probably going to depend on
gawk-4.1 (which has in-place edit feature) and use it explicitely in
rebar.eclass and some other ebuilds where I meant to use eawk. robbat2
has already requested stabilization of gawk-4.1.

Thanks,
-- Amadeusz Żołnowski


signature.asc
Description: PGP signature

Re: [gentoo-dev] [PATCH] rebar.eclass: Build Erlang/OTP projects using dev-util/rebar

[Michał Górny]

On Sat, 21 May 2016 14:26:00 +0100
aide...@gentoo.org wrote:

> From: Amadeusz Żołnowski 
> 
> It is an eclass providing functions to build Erlang/OTP projects using
> dev-util/rebar. All packages in upcoming category dev-erlang are going
> to use this eclass.
> ---
>  eclass/rebar.eclass | 217 
> 
>  1 file changed, 217 insertions(+)
>  create mode 100644 eclass/rebar.eclass
> 
> diff --git a/eclass/rebar.eclass b/eclass/rebar.eclass
> new file mode 100644
> index 000..9da1340
> --- /dev/null
> +++ b/eclass/rebar.eclass
> @@ -0,0 +1,217 @@
> +# Copyright 1999-2016 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +# $Id$
> +
> +# @ECLASS: rebar.eclass
> +# @MAINTAINER:
> +# Amadeusz Żołnowski 
> +# @AUTHOR:
> +# Amadeusz Żołnowski 
> +# @BLURB: Build Erlang/OTP projects using dev-util/rebar.
> +# @DESCRIPTION:
> +# An eclass providing functions to build Erlang/OTP projects using
> +# dev-util/rebar.
> +#
> +# rebar is a tool which tries to resolve dependencies itself which is by
> +# cloning remote git repositories. Dependant projects are usually expected to
> +# be in sub-directory 'deps' rather than looking at system Erlang lib
> +# directory. Projects relying on rebar usually don't have 'install' make
> +# targets. The eclass workarounds some of these problems. It handles
> +# installation in a generic way for Erlang/OTP structured projects.
> +
> +case "${EAPI:-0}" in
> + 0|1|2|3|4|5)
> + die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
> + ;;
> + 6)
> + ;;
> + *)
> + die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
> + ;;
> +esac
> +
> +inherit eutils
> +
> +EXPORT_FUNCTIONS src_prepare src_compile src_install
> +
> +RDEPEND="dev-lang/erlang"
> +DEPEND="${RDEPEND}
> + dev-util/rebar"
> +
> +# @ECLASS-VARIABLE: REBAR_APP_SRC
> +# @DESCRIPTION:
> +# Relative path to .app.src description file.
> +REBAR_APP_SRC="${REBAR_APP_SRC-src/${PN}.app.src}"
> +
> +# @FUNCTION: get_erl_libs
> +# @RETURN: the path to Erlang lib directory
> +# @DESCRIPTION:
> +# Get the full path without EPREFIX to Erlang lib directory.
> +get_erl_libs() {
> + echo "/usr/$(get_libdir)/erlang/lib"
> +}
> +
> +# @FUNCTION: _rebar_find_dep_version
> +# @INTERNAL
> +# @USAGE: 
> +# @RETURN: full path with EPREFIX to a Erlang package/project
> +# @DESCRIPTION:
> +# Find a Erlang package/project by name in Erlang lib directory. Project
> +# directory is usually suffixed with version. First match to  
> or
> +# -* is returned.
> +_rebar_find_dep_version() {
> + local pn="$1"
> + local p
> +
> + pushd "${EPREFIX}$(get_erl_libs)" >/dev/null || die
> + for p in ${pn} ${pn}-*; do
> + if [[ -d ${p} ]]; then
> + echo "${p#${pn}-}"
> + break
> + fi
> + done
> + popd >/dev/null || die
> +
> + [[ -d ${p} ]]
> +}
> +
> +# @FUNCTION: erebar
> +# @USAGE: 
> +# @DESCRIPTION:
> +# Run rebar with verbose flag. Die on failure.
> +erebar() {
> + debug-print-function ${FUNCNAME} "${@}"
> +
> + (( $# > 0 )) || die 'erebar: at least one target is required'

Why not [[ $# -gt 0 ]]? It's the first time I see someone using (( ))
for conditionals.

> +
> + evar_push ERL_LIBS
> + export ERL_LIBS="${EPREFIX}$(get_erl_libs)"

local -x ERL_LIBS=...

We don't really have to employ terribly ugly eval hackery to have
a local variable.

> + rebar -v skip_deps=true "$@" || die "rebar $@ failed"
> + evar_pop
> +}
> +
> +# @FUNCTION: rebar_fix_include_path
> +# @USAGE: 
> +# @DESCRIPTION:
> +# Fix path in rebar.config to 'include' directory of dependant 
> project/package,
> +# so it points to installation in system Erlang lib rather than relative 
> 'deps'
> +# directory.
> +#
> +# The function dies on failure.
> +rebar_fix_include_path() {
> + debug-print-function ${FUNCNAME} "${@}"
> +
> + local pn="$1"
> + local erl_libs="${EPREFIX}$(get_erl_libs)"
> + local pv="$(_rebar_find_dep_version "${pn}")"
> +
> + eawk rebar.config \
> + -v erl_libs="${erl_libs}" -v pn="${pn}" -v pv="${pv}" \
> + '/^{[[:space:]]*erl_opts[[:space:]]*,/, /}[[:space:]]*\.$/ {
> + pattern = "\"(./)?deps/" pn "/include\"";
> + if (match($0, "{i,[[:space:]]*" pattern "[[:space:]]*}")) {
> + sub(pattern, "\"" erl_libs "/" pn "-" pv "/include\"");
> + }
> + print $0;
> + next;
> +}
> +1
> +' || die "failed to fix include paths in rebar.config"

I meant indent like this:

+   eawk rebar.config \
+   -v erl_libs="${erl_libs}" -v pn="${pn}" -v pv="${pv}" \
+   '/^{[[:space:]]*erl_opts[[:space:]]*,/, /}[[:space:]]*\.$/ {
+   pattern = "\"(./)?deps/" pn "/include\"";
+   if (match($0, "{i,[[:space:]]*" 

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

[Michał Górny]

On Sat, 21 May 2016 14:49:41 +0100
aide...@gentoo.org wrote:

> From: Amadeusz Żołnowski 
> 
> 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.
> 
> New version of gawk (not stabilized yet) does support editing in place
> but forcing user to install specific awk implementation is not desired.
> ---
>  eclass/eutils.eclass| 16 +++
>  eclass/tests/eutils_eawk.sh | 66 
> +
>  2 files changed, 82 insertions(+)
>  create mode 100755 eclass/tests/eutils_eawk.sh
> 
> diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
> index dbedffe..963a692 100644
> --- a/eclass/eutils.eclass
> +++ b/eclass/eutils.eclass
> @@ -20,6 +20,22 @@ _EUTILS_ECLASS=1
>  
>  inherit multilib toolchain-funcs
>  
> +# @FUNCTION: eawk
> +# @USAGE:  
> +# @DESCRIPTION:
> +# Edit file  in place with awk. Pass all arguments following  to
> +# awk.
> +eawk() {
> + local f="$1"; shift
> + local tmpf="$(emktemp)"
> +
> + awk "$@" "${f}" >"${tmpf}" || die -n 'awk failed' || return

You can't use 'die -n' before EAPI 6. So you either need a conditional
there, or make the function available only in EAPI 6.

> + # Following commands should always succeed unless something weird is 
> going
> + # on.
> + cat "${tmpf}" >"${f}" || die 'failed to replace source file' || return
> + rm "${tmpf}" || die "failed to remove temporary file"

Any reason not to use mv here? Aside to making this simpler, it would
also prevent this from rewriting contents of hardlinked files.

> +}
> +
>  # @FUNCTION: eqawarn
>  # @USAGE: [message]
>  # @DESCRIPTION:
> diff --git a/eclass/tests/eutils_eawk.sh b/eclass/tests/eutils_eawk.sh
> new file mode 100755
> index 000..7e0d1d4
> --- /dev/null
> +++ b/eclass/tests/eutils_eawk.sh
> @@ -0,0 +1,66 @@
> +#!/bin/bash
> +# Copyright 1999-2016 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +# $Id$
> +
> +source tests-common.sh
> +
> +inherit eutils
> +
> +# Mock die so it doesn't break tests.
> +die() {
> + echo "die: $*" 1>&2
> + return 1
> +}
> +
> +tbegin "preserves permissions"
> +
> +cd "${tmpdir}" || tend $?

This doesn't terminate tests. So you'll end up creating files
in the wrong directory.

> +
> +cat <'test.txt'

Then, you aren't checking for failure here.

> +testme1
> +testme2
> +testme3
> +EOF
> +
> +cat <'test_expected.txt'
> +testme1
> +foo
> +testme3
> +EOF
> +
> +chmod 704 'test.txt' || tend $?
> +eumask_push 000
> +eawk 'test.txt' '/^testme2$/ {print "foo"; next;} 1' || tend $?
> +eumask_pop
> +
> +diff 'test.txt' 'test_expected.txt'
> +expected=$?
> +
> +[[ $(stat -c '%a' 'test.txt') = 704 ]]
> +perms=$?
> +
> +[[ ${expected}${perms} = 00 ]]
> +
> +tend $?
> +
> +
> +tbegin "doesn't alter file on failure"
> +
> +cd "${tmpdir}" || tend $?
> +
> +cat <'test.txt'
> +testme1
> +testme2
> +testme3
> +EOF
> +
> +cat 'test.txt' >'test_expected.txt'
> +
> +# eawk should file because of syntax error.
> +eawk 'test.txt' '/^testme2$/ print "foo"; next;} 1' 2>/dev/null && tend 1
> +diff 'test.txt' 'test_expected.txt'
> +
> +tend $?
> +
> +texit



-- 
Best regards,
Michał Górny



pgpiOnYMD5fAX.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] distutils-r1.eclass: Do not modify the HOME variable

[Michał Górny]

On Fri,  6 May 2016 09:25:50 -0400
Mike Gilbert  wrote:

> This was only necessary when we ran phases in parallel.
> Also, PMS says this variable should not be modified.
> ---
>  eclass/distutils-r1.eclass | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
> index 7965e91..497bed5 100644
> --- a/eclass/distutils-r1.eclass
> +++ b/eclass/distutils-r1.eclass
> @@ -628,12 +628,6 @@ distutils-r1_run_phase() {
>   # in the sys.path_importer_cache)
>   mkdir -p "${BUILD_DIR}/lib" || die
>  
> - # We need separate home for each implementation, for .pydistutils.cfg.
> - if [[ ! ${DISTUTILS_SINGLE_IMPL} ]]; then
> - local -x HOME=${HOME}/${EPYTHON}
> - mkdir -p "${HOME}" || die
> - fi
> -
>   # Set up build environment, bug #513664.
>   local -x AR=${AR} CC=${CC} CPP=${CPP} CXX=${CXX}
>   tc-export AR CC CPP CXX

I have merged this one as well to have both distutils-r1 changes
in a single cache regen.

-- 
Best regards,
Michał Górny



pgpYI0BN_yPNT.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] distutils-r1.eclass: Do not apply patches if DISTUTILS_OPTIONAL is used

[Michał Górny]

On Sun, 15 May 2016 11:30:00 +0200
Michał Górny  wrote:

> Do not apply PATCHES and user patches (either via the EAPI 6 default or
> pre-EAPI 5 code) when DISTUTILS_OPTIONAL is being used. In this case,
> distutils functions are usually called conditionally, in a subdirectory,
> while both PATCHES and user patches are usually intended to be applied
> top-level.
> 
> There is no ebuild relying on distutils-r1_src_prepare applying patches
> with DISTUTILS_OPTIONAL. In fact, there are ebuilds which work around
> this behavior.
> ---
>  eclass/distutils-r1.eclass | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
> index e8de5ad..afd29ed 100644
> --- a/eclass/distutils-r1.eclass
> +++ b/eclass/distutils-r1.eclass
> @@ -315,11 +315,13 @@ _distutils-r1_disable_ez_setup() {
>  distutils-r1_python_prepare_all() {
>   debug-print-function ${FUNCNAME} "${@}"
>  
> - if [[ ${EAPI} != [45] ]]; then
> - default
> - else
> - [[ ${PATCHES} ]] && epatch "${PATCHES[@]}"
> - epatch_user
> + if [[ ! ${DISTUTILS_OPTIONAL} ]]; then
> + if [[ ${EAPI} != [45] ]]; then
> + default
> + else
> + [[ ${PATCHES} ]] && epatch "${PATCHES[@]}"
> + epatch_user
> + fi
>   fi
>  
>   # by default, use in-source build if python_prepare() is used

Merged.

-- 
Best regards,
Michał Górny



pgpANQ1_HcyNE.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [RFC] How to deal with LINGUAS mess?

[Michał Górny]

On Sat, 21 May 2016 11:00:08 +0200
Ulrich Mueller  wrote:

> > On Sat, 21 May 2016, Michał Górny wrote:  
> 
> > I see the following possibilities:  
> 
> > 1. We start explicitly listing linguas_* in all ebuilds, no matter
> > how tiny they are. Maintainers are required to keep IUSE up-to-date
> > and users are forced to rebuild a lot.  
> 
> Why would users have to rebuild more often? Language support in a
> package will change with a version bump, when they must rebuild in any
> case.

Except whenever:

1. developer fails to update lingua list, and needs to do so afterwards,

2. user changes his preference (i.e. I just built my system and figured
out I should really strip those damn locales),

3. user attempts to use binary packages (unless someone goes for
providing 2^n binary package variants).

> 
> > This is also a QA violation in terms of invalid use of USE flags.  
> 
> I fail to see why this would be a QA violation.

It falls into the rule for controlling installation of small files.
Most of localizations are < 20 KiB.

-- 
Best regards,
Michał Górny



pgpBCGwfX8BiN.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] How to deal with LINGUAS mess?

[waltdnes]

On Sat, May 21, 2016 at 09:41:28AM +0200, Micha?? Górny wrote

> I see the following possibilities:
> 
> 1. We start explicitly listing linguas_* in all ebuilds, no matter how
> tiny they are. Maintainers are required to keep IUSE up-to-date
> and users are forced to rebuild a lot. This is also a QA violation
> in terms of invalid use of USE flags.
> 
> 2. We hack-unset LINGUAS in ebuilds. This is a lot of effort, easy to
> miss and probably would need to repeated for every single phase anyway
> due to how global variables are handled in PMS. Additionally, it may
> break at some point since those variables are likely expected to be
> read-only anyway.
> 
> 3. We remove LINGUAS from USE_EXPAND and stop using it. If ebuilds have
> a good reason to use flags for localization, we introduce a new,
> non-colliding USE_EXPAND for that. We also ask users to replace LINGUAS
> with the new flag in their make.conf files. LINGUAS gets the original
> upstream behavior back, and we eventually discourage it in favor of new
> INSTALL_MASK features (WiP) [2].
> 
> 4. We fix build systems not to do magic depending on whether LINGUAS
> is unset or set-to-empty. Instead, we could some special special value
> like '-' to signify not installing localizations at all. But that's
> upstream thing to do, and breaks backwards compatibility with existing
> systems disabling localizations.
> 
> 
> Your thoughts?

5. An reversed variant of INSTALL_MASK in make.conf, e.g.
LOCALE_ALLOW="foo bar fubar"

which would block installing files in /usr/share/locale/* and
/usr/share/man/* EXCEPT for...

/usr/share/locale/foo
/usr/share/locale/bar
/usr/share/locale/fubar
/usr/share/man/foo
/usr/share/man/bar
/usr/share/man/fubar

6. Integrate localepurge into Portage, and run it post install

  There are some lazy programmers out there who *DO NOT* respect the
LINGUAS setting, and splatter files throughout /usr/share/locale/* and
/usr/share/man/* regardless.  That's the reason "localepurge" was
written in the first place.  Any proposed solution should take that
problem into consideration, and handle it too.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

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

[Kristian Fiskerstrand]

On 05/21/2016 06:08 PM, Amadeusz Żołnowski wrote:
> Mike Frysinger  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. 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?

Is the use-case sufficiently common for it to be sourced in all ebuilds
inheriting eutils?

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Amadeusz Żołnowski]

Mike Frysinger  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. 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?

-- Amadeusz Żołnowski


signature.asc
Description: PGP signature

[gentoo-dev] Package up for grabs

[Pacho Ramos]

Because of the current maintainer not having time to take care of them,
the following packages are now up for grabs:
app-misc/astrolog

[gentoo-dev] Package up for grabs

[Pacho Ramos]

Because of the current maintainer not having time to take care of them,
the following packages are now up for grabs:
dev-db/freetds
dev-db/libiodbc
dev-libs/libxdiff
net-libs/rabbitmq-c

[gentoo-dev] Package up for grabs

[Pacho Ramos]

Because of the current maintainer not having time to take care of them,
the following packages are now up for grabs:
dev-python/edpwd
net-mail/mhonarc-gentoo

[gentoo-dev] Package up for grabs

[Pacho Ramos]

Because of the current maintainer not having time to take care of them,
the following packages are now up for grabs:
games-simulation/corsix-th
media-sound/gnaural

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

[gentoo-dev] Package up for grabs

[Pacho Ramos]

Because of the current maintainer not having time to take care of them,
the following packages are now up for grabs:
net-misc/tightvnc
sys-fs/davl

[gentoo-dev] Package up for grabs

[Pacho Ramos]

Because of the current maintainer not having time to take care of them,
the following packages are now up for grabs:
app-cdr/cdck
dev-util/heaptrack
sys-process/wait_on_pid

Re: [gentoo-dev] Package up for grabs

[Ulrich Mueller]

> On Sat, 21 May 2016, Pacho Ramos wrote:

> Because of the current maintainer not having time to take care of
> them, the following packages are now up for grabs:
> app-editors/joe
> dev-lang/ucblogo
> www-apache/mod_limitipconn

The Emacs team will take app-editors/joe unless someone else wants it.

Ulrich


pgpliPQosYD0J.pgp
Description: PGP signature

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

[aidecoe]

From: Amadeusz Żołnowski 

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.

New version of gawk (not stabilized yet) does support editing in place
but forcing user to install specific awk implementation is not desired.
---
 eclass/eutils.eclass| 16 +++
 eclass/tests/eutils_eawk.sh | 66 +
 2 files changed, 82 insertions(+)
 create mode 100755 eclass/tests/eutils_eawk.sh

diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
index dbedffe..963a692 100644
--- a/eclass/eutils.eclass
+++ b/eclass/eutils.eclass
@@ -20,6 +20,22 @@ _EUTILS_ECLASS=1
 
 inherit multilib toolchain-funcs
 
+# @FUNCTION: eawk
+# @USAGE:  
+# @DESCRIPTION:
+# Edit file  in place with awk. Pass all arguments following  to
+# awk.
+eawk() {
+   local f="$1"; shift
+   local tmpf="$(emktemp)"
+
+   awk "$@" "${f}" >"${tmpf}" || die -n 'awk failed' || return
+   # Following commands should always succeed unless something weird is 
going
+   # on.
+   cat "${tmpf}" >"${f}" || die 'failed to replace source file' || return
+   rm "${tmpf}" || die "failed to remove temporary file"
+}
+
 # @FUNCTION: eqawarn
 # @USAGE: [message]
 # @DESCRIPTION:
diff --git a/eclass/tests/eutils_eawk.sh b/eclass/tests/eutils_eawk.sh
new file mode 100755
index 000..7e0d1d4
--- /dev/null
+++ b/eclass/tests/eutils_eawk.sh
@@ -0,0 +1,66 @@
+#!/bin/bash
+# Copyright 1999-2016 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Id$
+
+source tests-common.sh
+
+inherit eutils
+
+# Mock die so it doesn't break tests.
+die() {
+   echo "die: $*" 1>&2
+   return 1
+}
+
+tbegin "preserves permissions"
+
+cd "${tmpdir}" || tend $?
+
+cat <'test.txt'
+testme1
+testme2
+testme3
+EOF
+
+cat <'test_expected.txt'
+testme1
+foo
+testme3
+EOF
+
+chmod 704 'test.txt' || tend $?
+eumask_push 000
+eawk 'test.txt' '/^testme2$/ {print "foo"; next;} 1' || tend $?
+eumask_pop
+
+diff 'test.txt' 'test_expected.txt'
+expected=$?
+
+[[ $(stat -c '%a' 'test.txt') = 704 ]]
+perms=$?
+
+[[ ${expected}${perms} = 00 ]]
+
+tend $?
+
+
+tbegin "doesn't alter file on failure"
+
+cd "${tmpdir}" || tend $?
+
+cat <'test.txt'
+testme1
+testme2
+testme3
+EOF
+
+cat 'test.txt' >'test_expected.txt'
+
+# eawk should file because of syntax error.
+eawk 'test.txt' '/^testme2$/ print "foo"; next;} 1' 2>/dev/null && tend 1
+diff 'test.txt' 'test_expected.txt'
+
+tend $?
+
+texit
-- 
2.8.2

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

[Amadeusz Żołnowski]

aide...@gentoo.org writes:
> +tbegin "preserves permissions"
> +
> +cd "$(emktemp -d)"

tests-common.sh already creates tmp directory, so better would be:

  cd "${tmpdir}" || tend $?

-- Amadeusz Żołnowski


signature.asc
Description: PGP signature

[gentoo-dev] Package up for grabs

[Pacho Ramos]

Because of the current maintainer not having time to take care of them,
the following packages are now up for grabs:
media-sound/aacgain
net-dialup/dtrace

[gentoo-dev] Package up for grabs

[Pacho Ramos]

Because of the current maintainer not having time to take care of them,
the following packages are now up for grabs:
dev-lang/io
dev-lang/srf

[gentoo-dev] [PATCH] rebar.eclass: Build Erlang/OTP projects using dev-util/rebar

[aidecoe]

From: Amadeusz Żołnowski 

It is an eclass providing functions to build Erlang/OTP projects using
dev-util/rebar. All packages in upcoming category dev-erlang are going
to use this eclass.
---
 eclass/rebar.eclass | 217 
 1 file changed, 217 insertions(+)
 create mode 100644 eclass/rebar.eclass

diff --git a/eclass/rebar.eclass b/eclass/rebar.eclass
new file mode 100644
index 000..9da1340
--- /dev/null
+++ b/eclass/rebar.eclass
@@ -0,0 +1,217 @@
+# Copyright 1999-2016 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Id$
+
+# @ECLASS: rebar.eclass
+# @MAINTAINER:
+# Amadeusz Żołnowski 
+# @AUTHOR:
+# Amadeusz Żołnowski 
+# @BLURB: Build Erlang/OTP projects using dev-util/rebar.
+# @DESCRIPTION:
+# An eclass providing functions to build Erlang/OTP projects using
+# dev-util/rebar.
+#
+# rebar is a tool which tries to resolve dependencies itself which is by
+# cloning remote git repositories. Dependant projects are usually expected to
+# be in sub-directory 'deps' rather than looking at system Erlang lib
+# directory. Projects relying on rebar usually don't have 'install' make
+# targets. The eclass workarounds some of these problems. It handles
+# installation in a generic way for Erlang/OTP structured projects.
+
+case "${EAPI:-0}" in
+   0|1|2|3|4|5)
+   die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
+   ;;
+   6)
+   ;;
+   *)
+   die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
+   ;;
+esac
+
+inherit eutils
+
+EXPORT_FUNCTIONS src_prepare src_compile src_install
+
+RDEPEND="dev-lang/erlang"
+DEPEND="${RDEPEND}
+   dev-util/rebar"
+
+# @ECLASS-VARIABLE: REBAR_APP_SRC
+# @DESCRIPTION:
+# Relative path to .app.src description file.
+REBAR_APP_SRC="${REBAR_APP_SRC-src/${PN}.app.src}"
+
+# @FUNCTION: get_erl_libs
+# @RETURN: the path to Erlang lib directory
+# @DESCRIPTION:
+# Get the full path without EPREFIX to Erlang lib directory.
+get_erl_libs() {
+   echo "/usr/$(get_libdir)/erlang/lib"
+}
+
+# @FUNCTION: _rebar_find_dep_version
+# @INTERNAL
+# @USAGE: 
+# @RETURN: full path with EPREFIX to a Erlang package/project
+# @DESCRIPTION:
+# Find a Erlang package/project by name in Erlang lib directory. Project
+# directory is usually suffixed with version. First match to  or
+# -* is returned.
+_rebar_find_dep_version() {
+   local pn="$1"
+   local p
+
+   pushd "${EPREFIX}$(get_erl_libs)" >/dev/null || die
+   for p in ${pn} ${pn}-*; do
+   if [[ -d ${p} ]]; then
+   echo "${p#${pn}-}"
+   break
+   fi
+   done
+   popd >/dev/null || die
+
+   [[ -d ${p} ]]
+}
+
+# @FUNCTION: erebar
+# @USAGE: 
+# @DESCRIPTION:
+# Run rebar with verbose flag. Die on failure.
+erebar() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   (( $# > 0 )) || die 'erebar: at least one target is required'
+
+   evar_push ERL_LIBS
+   export ERL_LIBS="${EPREFIX}$(get_erl_libs)"
+   rebar -v skip_deps=true "$@" || die "rebar $@ failed"
+   evar_pop
+}
+
+# @FUNCTION: rebar_fix_include_path
+# @USAGE: 
+# @DESCRIPTION:
+# Fix path in rebar.config to 'include' directory of dependant project/package,
+# so it points to installation in system Erlang lib rather than relative 'deps'
+# directory.
+#
+# The function dies on failure.
+rebar_fix_include_path() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local pn="$1"
+   local erl_libs="${EPREFIX}$(get_erl_libs)"
+   local pv="$(_rebar_find_dep_version "${pn}")"
+
+   eawk rebar.config \
+   -v erl_libs="${erl_libs}" -v pn="${pn}" -v pv="${pv}" \
+   '/^{[[:space:]]*erl_opts[[:space:]]*,/, /}[[:space:]]*\.$/ {
+   pattern = "\"(./)?deps/" pn "/include\"";
+   if (match($0, "{i,[[:space:]]*" pattern "[[:space:]]*}")) {
+   sub(pattern, "\"" erl_libs "/" pn "-" pv "/include\"");
+   }
+   print $0;
+   next;
+}
+1
+' || die "failed to fix include paths in rebar.config"
+}
+
+# @FUNCTION: rebar_remove_deps
+# @DESCRIPTION:
+# Remove dependencies list from rebar.config and deceive build rules that any
+# dependencies are already fetched and built. Otherwise rebar tries to fetch
+# dependencies and compile them.
+#
+# The function dies on failure.
+rebar_remove_deps() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   mkdir -p "${S}/deps" && :>"${S}/deps/.got" && :>"${S}/deps/.built" || 
die
+   eawk rebar.config \
+   '/^{[[:space:]]*deps[[:space:]]*,/, /}[[:space:]]*\.$/ {
+   if ($0 ~ /}[[:space:]]*\.$/) {
+   print "{deps, []}.";
+   }
+   next;
+}
+1
+' || die "failed to remove deps from rebar.config"
+}
+
+# @FUNCTION: rebar_set_vsn
+# @USAGE: []
+# @DESCRIPTION:
+# Set version in project 

[gentoo-dev] Package up for grabs

[Pacho Ramos]

Because of the current maintainer not having time to take care of them,
the following packages are now up for grabs:
app-editors/joe
dev-lang/ucblogo
www-apache/mod_limitipconn

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

[aidecoe]

From: Amadeusz Żołnowski 

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.

New version of gawk (not stabilized yet) does support editing in place
but forcing user to install specific awk implementation is not desired.
---
 eclass/eutils.eclass| 16 +++
 eclass/tests/eutils_eawk.sh | 65 +
 2 files changed, 81 insertions(+)
 create mode 100755 eclass/tests/eutils_eawk.sh

diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
index dbedffe..963a692 100644
--- a/eclass/eutils.eclass
+++ b/eclass/eutils.eclass
@@ -20,6 +20,22 @@ _EUTILS_ECLASS=1
 
 inherit multilib toolchain-funcs
 
+# @FUNCTION: eawk
+# @USAGE:  
+# @DESCRIPTION:
+# Edit file  in place with awk. Pass all arguments following  to
+# awk.
+eawk() {
+   local f="$1"; shift
+   local tmpf="$(emktemp)"
+
+   awk "$@" "${f}" >"${tmpf}" || die -n 'awk failed' || return
+   # Following commands should always succeed unless something weird is 
going
+   # on.
+   cat "${tmpf}" >"${f}" || die 'failed to replace source file' || return
+   rm "${tmpf}" || die "failed to remove temporary file"
+}
+
 # @FUNCTION: eqawarn
 # @USAGE: [message]
 # @DESCRIPTION:
diff --git a/eclass/tests/eutils_eawk.sh b/eclass/tests/eutils_eawk.sh
new file mode 100755
index 000..b06f377
--- /dev/null
+++ b/eclass/tests/eutils_eawk.sh
@@ -0,0 +1,65 @@
+#!/bin/bash
+# Copyright 1999-2016 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Id$
+
+source tests-common.sh
+
+inherit eutils
+
+# Mock die so it doesn't break tests.
+die() {
+   echo "die: $*" 1>&2
+   return 1
+}
+
+tbegin "preserves permissions"
+
+cd "$(emktemp -d)"
+
+cat <'test.txt'
+testme1
+testme2
+testme3
+EOF
+
+cat <'test_expected.txt'
+testme1
+foo
+testme3
+EOF
+
+chmod 704 'test.txt'
+eumask_push 000
+eawk 'test.txt' '/^testme2$/ {print "foo"; next;} 1'
+eumask_pop
+
+diff 'test.txt' 'test_expected.txt'
+expected=$?
+
+[[ $(stat -c '%a' 'test.txt') = 704 ]]
+perms=$?
+
+[[ ${expected}${perms} = 00 ]]
+
+tend $?
+
+
+tbegin "doesn't alter file on failure"
+
+cd "$(emktemp -d)"
+
+cat <'test.txt'
+testme1
+testme2
+testme3
+EOF
+
+cat 'test.txt' >'test_expected.txt'
+
+eawk 'test.txt' '/^testme2$/ print "foo"; next;} 1' 2>/dev/null
+diff 'test.txt' 'test_expected.txt'
+
+tend $?
+
+texit
-- 
2.8.2

Re: [gentoo-dev] [RFC] How to deal with LINGUAS mess?

[Michael Orlitzky]

On 05/21/2016 03:41 AM, Michał Górny wrote:
> 
> I see the following possibilities:
> 

#2 is ugly and requires a special case due to a bad choice of variable
name; #4 will never work.


> 3. We remove LINGUAS from USE_EXPAND and stop using it. If ebuilds have
> a good reason to use flags for localization, we introduce a new,
> non-colliding USE_EXPAND for that. We also ask users to replace LINGUAS
> with the new flag in their make.conf files. LINGUAS gets the original
> upstream behavior back, and we eventually discourage it in favor of new
> INSTALL_MASK features (WiP) [2].
> 

This is probably the best option because it fixes the real problem: we
tried to repurpose somebody else's environment variable for our package
manager. If we try to keep the name "LINGUAS", we may run into some
other problem down the line.


> 1. We start explicitly listing linguas_* in all ebuilds, no matter how
> tiny they are. Maintainers are required to keep IUSE up-to-date
> and users are forced to rebuild a lot. This is also a QA violation
> in terms of invalid use of USE flags.

This isn't as bad as you make it sound... the rebuilds would happen once
on a revision bump. The QA violation (I'm guessing) is that USE flags
shouldn't be used to control the installation of small text files.

I prefer a looser interpretation of that rule: maintainers don't have to
waste their time and complicate their ebuilds with USE flags to control
the installation of small text files if they don't want to. Basically an
"it's OK to install systemd unit files unconditionally" rule. Or in
other words, the rule is "it's OK not to do it" rather than "it's not OK
to do it."

I think if someone /wants/ to have a bunch of logic controlling the
installation of localization files, that's fine. But, this option would
force everyone to do it in order to work around an unfortunate choice of
variable name. It also adds some eternal mental overhead in that we have
to collectively remember that LINGUAS is special somehow and teach that
to everyone.

For those reasons I think #3 is a better long-term solution.

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

[Amadeusz Żołnowski]

Amadeusz Żołnowski  writes:
> Indeed. So one of these:
>
>   a) eawk  
>   b) eawk  -- 
>   c) eawk  -- 

Ups, actually (c) wouldn't be correct either, so only (a) and (b) and
I'd just stick to (a) to not complicate things.

-- 
Amadeusz Żołnowski


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: [RFC] How to deal with LINGUAS mess?

[Ulrich Mueller]

> On Sat, 21 May 2016, Kent Fredric wrote:

> On 21 May 2016 at 21:00, Ulrich Mueller  wrote:
>> Why would users have to rebuild more often? Language support in a
>> package will change with a version bump, when they must rebuild in
>> any case.

> But changing IUSE would cause users to cause rebuilds under
> --new-use, even though no actual changes happened ( this happens a
> bit as it is ).

They would have to rebuild the package once, when linguas_* flags
are first added to IUSE. After that, I don't see what would trigger
additional rebuilds outside of a version bump.

Ulrich


pgpvStPhMeoGb.pgp
Description: PGP signature

Re: [gentoo-dev] Re: [RFC] How to deal with LINGUAS mess?

[Kent Fredric]

On 21 May 2016 at 21:00, Ulrich Mueller  wrote:
> Why would users have to rebuild more often? Language support in a
> package will change with a version bump, when they must rebuild in any
> case.


But changing IUSE would cause users to cause rebuilds under --new-use,
even though no actual changes happened ( this happens a bit as it is
).

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] new developers' keyword requests

[Jeroen Roovers]

On Fri, 20 May 2016 21:47:56 -0700
Matt Turner  wrote:

> On Thu, May 19, 2016 at 6:36 PM, Daniel Campbell 
> wrote:
> > To make sure I understand what you're getting at, are you saying
> > some devs get on board and then request to add keywords to packages
> > that they already maintain?  
> 
> No, you've misunderstood.
> 
> He's saying people add new packages and then speculatively add
> keywords for a bunch of architectures that they haven't tested.

No, that's already covered very well in the quizzes and devmanual.

What I mean is keyword requests of the type: "Hi, I maintain this
package now, and I'm very excited about it, so can I have these random
keywords added, please?"

I have plenty of examples of such keyword requests collected over the
years; anyone should be able to find them easily.


Regards,
 jer

[gentoo-dev] Re: [RFC] How to deal with LINGUAS mess?

[Ulrich Mueller]

> On Sat, 21 May 2016, Michał Górny wrote:

> I see the following possibilities:

> 1. We start explicitly listing linguas_* in all ebuilds, no matter
> how tiny they are. Maintainers are required to keep IUSE up-to-date
> and users are forced to rebuild a lot.

Why would users have to rebuild more often? Language support in a
package will change with a version bump, when they must rebuild in any
case.

> This is also a QA violation in terms of invalid use of USE flags.

I fail to see why this would be a QA violation.

> [...]

Ulrich


pgpTgukhJZ6RJ.pgp
Description: PGP signature

Re: [gentoo-dev] [PATCH] rebar.eclass: Build Erlang/OTP projects using dev-util/rebar

[Amadeusz Żołnowski]

Michał Górny  writes:
>> >> + [[ -d include ]] && doins -r include
>> >> + [[ -d bin ]] && for bin in bin/*; do dobin "$bin"; done  
>> >
>> > Please don't do inlines like this.  
>> 
>> Is there a particular problem with this?
>
> Readability and maintainability. At some point someone may want to
> extend this, and it will no longer work as one-liner.

That's rather subjective. Given the context I find concise. When
uninlined it takes 4 lines more, gets out of context and looks more
noisy to me. If someone would like to extend the inline version it could
be uninlined at that point.

-- 
Amadeusz Żołnowski


signature.asc
Description: PGP signature

Re: [gentoo-dev] [RFC] How to deal with LINGUAS mess?

[Kent Fredric]

On 21 May 2016 at 19:41, Michał Górny  wrote:
> Hello,
>
>
> Those of you who read my blog post on LINGUAS [1] may already know
> what's going on. For those who didn't, short summary:
>
> In EAPI 5 and newer, all variables listed in USE_EXPAND are supposed to
> be unconditionally exported with their values reduced to enabled USE
> flags listed in IUSE. In particular, this means that if ebuild does not
> list any linguas_* flags in IUSE, PM exports *empty* LINGUAS (i.e.
> disables all localizations with the implicit gettext behavior).
>
> Portage had so far some ugly hack-logic that tried to keep LINGUAS
> working somehow in place. However, the patches to enable PMS-compliant
> behavior are on their way, so it's about time to decide what to do
> about LINGUAS.
>
>
> I see the following possibilities:
>
> 1. We start explicitly listing linguas_* in all ebuilds, no matter how
> tiny they are. Maintainers are required to keep IUSE up-to-date
> and users are forced to rebuild a lot. This is also a QA violation
> in terms of invalid use of USE flags.
>
> 2. We hack-unset LINGUAS in ebuilds. This is a lot of effort, easy to
> miss and probably would need to repeated for every single phase anyway
> due to how global variables are handled in PMS. Additionally, it may
> break at some point since those variables are likely expected to be
> read-only anyway.
>
> 3. We remove LINGUAS from USE_EXPAND and stop using it. If ebuilds have
> a good reason to use flags for localization, we introduce a new,
> non-colliding USE_EXPAND for that. We also ask users to replace LINGUAS
> with the new flag in their make.conf files. LINGUAS gets the original
> upstream behavior back, and we eventually discourage it in favor of new
> INSTALL_MASK features (WiP) [2].
>
> 4. We fix build systems not to do magic depending on whether LINGUAS
> is unset or set-to-empty. Instead, we could some special special value
> like '-' to signify not installing localizations at all. But that's
> upstream thing to do, and breaks backwards compatibility with existing
> systems disabling localizations.
>
>
> Your thoughts?

I think its a regretful situation we find ourselves in where
portage/PMS control values that have to go via ENV, leak beyond ENV
into packaging.

This has already been a bit of a worry for us, because we may have
wanted to use PERL_ as a prefix for env vars in an eclass, but there's
a possibility of accidentally picking the same ENV var that is
inherently used in some perl part.
( And at very least, `perl -V` shows all ENV vars that are prefixed
with PERL_  eg: PERL_MOM_YOURS=1 perl -V )

Though I just don't see how we can generically avoid that scope
leakage, because this is bash, and we're short on private ways to pass
control values around, other than going crazy on functions.

The only thing I thought of when reading the writeup was tagged
install mask verbs.

That is:

- Always install all language support possible by default.
- Have an ebuild mapping of some description that annotates "files X
add support for languages ( y, z, x )"

And then maybe you'd have a parameterized INSTALL_MASK system where you could do

INSTALL_MASK_RULES="linguas(-* en)"

Then it would be "Packager decides" if they want to trip a rebuild at
the end user when they "discovered" certain files pertain to specific
language support.

Then the only reason you'd need USE flags is if you wanted to toggle
compile time support that pulled in dependencies to support the
language in question.


-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

[gentoo-dev] [RFC] How to deal with LINGUAS mess?

[Michał Górny]

Hello,


Those of you who read my blog post on LINGUAS [1] may already know
what's going on. For those who didn't, short summary:

In EAPI 5 and newer, all variables listed in USE_EXPAND are supposed to
be unconditionally exported with their values reduced to enabled USE
flags listed in IUSE. In particular, this means that if ebuild does not
list any linguas_* flags in IUSE, PM exports *empty* LINGUAS (i.e.
disables all localizations with the implicit gettext behavior).

Portage had so far some ugly hack-logic that tried to keep LINGUAS
working somehow in place. However, the patches to enable PMS-compliant
behavior are on their way, so it's about time to decide what to do
about LINGUAS.


I see the following possibilities:

1. We start explicitly listing linguas_* in all ebuilds, no matter how
tiny they are. Maintainers are required to keep IUSE up-to-date
and users are forced to rebuild a lot. This is also a QA violation
in terms of invalid use of USE flags.

2. We hack-unset LINGUAS in ebuilds. This is a lot of effort, easy to
miss and probably would need to repeated for every single phase anyway
due to how global variables are handled in PMS. Additionally, it may
break at some point since those variables are likely expected to be
read-only anyway.

3. We remove LINGUAS from USE_EXPAND and stop using it. If ebuilds have
a good reason to use flags for localization, we introduce a new,
non-colliding USE_EXPAND for that. We also ask users to replace LINGUAS
with the new flag in their make.conf files. LINGUAS gets the original
upstream behavior back, and we eventually discourage it in favor of new
INSTALL_MASK features (WiP) [2].

4. We fix build systems not to do magic depending on whether LINGUAS
is unset or set-to-empty. Instead, we could some special special value
like '-' to signify not installing localizations at all. But that's
upstream thing to do, and breaks backwards compatibility with existing
systems disabling localizations.


Your thoughts?


[1]:https://blogs.gentoo.org/mgorny/2016/05/16/how-linguas-are-thrice-wrong/
[2]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:INSTALL_MASK

-- 
Best regards,
Michał Górny



pgpTVRUQKVuVL.pgp
Description: OpenPGP digital signature

[gentoo-portage-dev] [PATCH v2 2/2] portage.package.ebuild.config: Always export filtered USE_EXPAND vars

[Michał Górny]

Ensure that all USE_EXPAND variables are always exported with filtered
USE flags inside, even if none of those flags are declared in IUSE.
This is the behavior required for EAPI 5+ by the PMS.

Since the behavior for earlier EAPIs is left undefined and having
different behavior would be confusing to users, apply it in earlier
EAPIs as well.
---
 bin/ebuild.sh|  6 
 pym/portage/package/ebuild/config.py | 55 ++--
 2 files changed, 3 insertions(+), 58 deletions(-)

diff --git a/bin/ebuild.sh b/bin/ebuild.sh
index 5b3146d..edf885f 100755
--- a/bin/ebuild.sh
+++ b/bin/ebuild.sh
@@ -690,12 +690,6 @@ if ! has "$EBUILD_PHASE" clean cleanrm ; then
fi
 fi
 
-# unset USE_EXPAND variables that contain only the special "*" token
-for x in ${USE_EXPAND} ; do
-   [ "${!x}" == "*" ] && unset ${x}
-done
-unset x
-
 if has nostrip ${FEATURES} ${RESTRICT} || has strip ${RESTRICT}
 then
export DEBUGBUILD=1
diff --git a/pym/portage/package/ebuild/config.py 
b/pym/portage/package/ebuild/config.py
index 5f19996..d92f5f6 100644
--- a/pym/portage/package/ebuild/config.py
+++ b/pym/portage/package/ebuild/config.py
@@ -1330,47 +1330,7 @@ class config(object):
filtered_var_split.append(x)
var_split = filtered_var_split
 
-   if var_split:
-   value = ' '.join(var_split)
-   else:
-   # Don't export empty USE_EXPAND vars unless the 
user config
-   # exports them as empty.  This is required for 
vars such as
-   # LINGUAS, where unset and empty have different 
meanings.
-   # The special '*' token is understood by 
ebuild.sh, which
-   # will unset the variable so that things like 
LINGUAS work
-   # properly (see bug #459350).
-   if has_wildcard:
-   value = '*'
-   else:
-   if has_iuse:
-   already_set = False
-   # Skip the first 'env' 
configdict, in order to
-   # avoid infinite recursion 
here, since that dict's
-   # __getitem__ calls the current 
__getitem__.
-   for d in 
self._settings.lookuplist[1:]:
-   if key in d:
-   already_set = 
True
-   break
-
-   if not already_set:
-   for x in 
self._unfiltered_use:
-   if 
x[:prefix_len] == prefix:
-   
already_set = True
-   break
-
-   if already_set:
-   value = ''
-   else:
-   value = '*'
-   else:
-   # It's not in IUSE, so just 
allow the variable content
-   # to pass through if it is 
defined somewhere.  This
-   # allows packages that support 
LINGUAS but don't
-   # declare it in IUSE to use the 
variable outside of the
-   # USE_EXPAND context.
-   value = None
-
-   return value
+   return ' '.join(var_split)
 
def setcpv(self, mycpv, use_cache=None, mydb=None):
"""
@@ -1727,7 +1687,7 @@ class config(object):
self, unfiltered_use, use, self.usemask,
portage_iuse, use_expand_split, self._use_expand_dict)
 
-   use_expand_iuses = {}
+   use_expand_iuses = dict((k, set()) for k in use_expand_split)
for x in portage_iuse:
x_split = x.split('_')
if len(x_split) == 1:
@@ -1735,18 +1695,9 @@ class config(object):
for i in range(len(x_split) - 1):
k = '_'.join(x_split[:i+1])
if k in use_expand_split:
-

[gentoo-portage-dev] [PATCH v2 1/2] portage.package.ebuild.config: Rename iuse_implicit -> iuse_effective

[Michał Górny]

Rename the iuse_implicit variable used in USE_EXPAND handling to
iuse_effective, since that is what is actually passed there. Correct
naming makes figuring out what the function does much easier.
---
 pym/portage/package/ebuild/config.py | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/pym/portage/package/ebuild/config.py 
b/pym/portage/package/ebuild/config.py
index 45b7d08..5f19996 100644
--- a/pym/portage/package/ebuild/config.py
+++ b/pym/portage/package/ebuild/config.py
@@ -1278,13 +1278,13 @@ class config(object):
"""
 
def __init__(self, settings, unfiltered_use,
-   use, usemask, iuse_implicit,
+   use, usemask, iuse_effective,
use_expand_split, use_expand_dict):
self._settings = settings
self._unfiltered_use = unfiltered_use
self._use = use
self._usemask = usemask
-   self._iuse_implicit = iuse_implicit
+   self._iuse_effective = iuse_effective
self._use_expand_split = use_expand_split
self._use_expand_dict = use_expand_dict
 
@@ -1302,7 +1302,7 @@ class config(object):
if has_wildcard:
var_split = [ x for x in var_split if x != "*" ]
has_iuse = set()
-   for x in self._iuse_implicit:
+   for x in self._iuse_effective:
if x[:prefix_len] == prefix:
has_iuse.add(x[prefix_len:])
if has_wildcard:
-- 
2.8.2

[gentoo-dev] Re: new developers' keyword requests

[Duncan]

Matt Turner posted on Fri, 20 May 2016 21:47:56 -0700 as excerpted:

> He's saying people add new packages and then speculatively add keywords
> for a bunch of architectures that they haven't tested. This causes
> unnecessary packages to be keyworded on archs that don't want them and
> can hardly afford the extra load.

I can even visualize the argument in support, too.

"Well, the package is known to work on that arch on Fedora..."

That may be, but has the package been actually tested to work on that 
arch within the gentoo context, and is it likely to be practical for the 
minor arch to continue to support?  It's not a question of whether it 
worked on fedora or not.  It's a question of whether it has been tested 
on gentoo or not, and whether that arch's users on gentoo find it useful 
enough to be worth the trouble to maintain over time and other software 
changes on that arch.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] [PATCH] rebar.eclass: Build Erlang/OTP projects using dev-util/rebar

[Michał Górny]

On Sat, 21 May 2016 00:06:01 +0100
Amadeusz Żołnowski  wrote:

> >> +rebar_src_install() {
> >> +  debug-print-function ${FUNCNAME} "${@}"
> >> +
> >> +  local bin
> >> +  local dest="$(get_erl_libs)/${P}"
> >> +
> >> +  insinto "${dest}"
> >> +  doins -r ebin
> >> +  [[ -d include ]] && doins -r include
> >> +  [[ -d bin ]] && for bin in bin/*; do dobin "$bin"; done  
> >
> > Please don't do inlines like this.  
> 
> Is there a particular problem with this?

Readability and maintainability. At some point someone may want to
extend this, and it will no longer work as one-liner.

-- 
Best regards,
Michał Górny



pgpKZpzxcpPIz.pgp
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH 2/2] ebuild.config: Fix filtering all USE_EXPAND variables in EAPI 5+

[Michał Górny]

On Sat, 21 May 2016 00:26:40 +0200
Michał Górny  wrote:

> Ensure that all USE_EXPAND variables are properly filtered and exported
> in EAPI 5 and newer, as required by the PMS. This includes exporting
> an empty value if no matching flag is provided in IUSE.
> 
> Bug: https://bugs.gentoo.org/show_bug.cgi?id=582140
> ---
>  pym/portage/eapi.py  |  6 +-
>  pym/portage/package/ebuild/config.py | 11 ---
>  2 files changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/pym/portage/eapi.py b/pym/portage/eapi.py
> index 1709026..c4fb374 100644
> --- a/pym/portage/eapi.py
> +++ b/pym/portage/eapi.py
> @@ -50,6 +50,9 @@ def eapi_exports_EBUILD_PHASE_FUNC(eapi):
>  def eapi_exports_REPOSITORY(eapi):
>   return eapi in ("4-python", "5-progress")
>  
> +def eapi_exports_USE_EXPAND_variables(eapi):
> + return eapi not in ("0", "1", "2", "3", "4", "4-python", "4-slot-abi")
> +
>  def eapi_has_pkg_pretend(eapi):
>   return eapi not in ("0", "1", "2", "3")
>  
> @@ -101,7 +104,7 @@ def eapi_has_targetroot(eapi):
>  
>  _eapi_attrs = collections.namedtuple('_eapi_attrs',
>   'dots_in_PN dots_in_use_flags exports_EBUILD_PHASE_FUNC '
> - 'feature_flag_test feature_flag_targetroot '
> + 'exports_USE_EXPAND_variables 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 '
>   'src_uri_arrows strong_blocks use_deps use_dep_defaults')
> @@ -128,6 +131,7 @@ def _get_eapi_attrs(eapi):
>   dots_in_PN = (eapi is None or eapi_allows_dots_in_PN(eapi)),
>   dots_in_use_flags = (eapi is None or 
> eapi_allows_dots_in_use_flags(eapi)),
>   exports_EBUILD_PHASE_FUNC = (eapi is None or 
> eapi_exports_EBUILD_PHASE_FUNC(eapi)),
> + exports_USE_EXPAND_variables = (eapi is None or 
> eapi_exports_USE_EXPAND_variables(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/config.py 
> b/pym/portage/package/ebuild/config.py
> index 5f19996..ee1fadb 100644
> --- a/pym/portage/package/ebuild/config.py
> +++ b/pym/portage/package/ebuild/config.py
> @@ -1279,7 +1279,7 @@ class config(object):
>  
>   def __init__(self, settings, unfiltered_use,
>   use, usemask, iuse_effective,
> - use_expand_split, use_expand_dict):
> + use_expand_split, use_expand_dict, 
> eapi_exports_USE_EXPAND_variables):
>   self._settings = settings
>   self._unfiltered_use = unfiltered_use
>   self._use = use
> @@ -1287,6 +1287,7 @@ class config(object):
>   self._iuse_effective = iuse_effective
>   self._use_expand_split = use_expand_split
>   self._use_expand_dict = use_expand_dict
> + self._eapi_exports_USE_EXPAND_variables = 
> eapi_exports_USE_EXPAND_variables
>  
>   def __getitem__(self, key):
>   prefix = key.lower() + '_'
> @@ -1330,7 +1331,7 @@ class config(object):
>   filtered_var_split.append(x)
>   var_split = filtered_var_split
>  
> - if var_split:
> + if var_split or self._eapi_exports_USE_EXPAND_variables:
>   value = ' '.join(var_split)
>   else:
>   # Don't export empty USE_EXPAND vars unless the 
> user config
> @@ -1725,9 +1726,13 @@ class config(object):
>   x in self.get('USE_EXPAND', '').split())
>   lazy_use_expand = self._lazy_use_expand(
>   self, unfiltered_use, use, self.usemask,
> - portage_iuse, use_expand_split, self._use_expand_dict)
> + portage_iuse, use_expand_split, self._use_expand_dict,
> + eapi_attrs.exports_USE_EXPAND_variables)
>  
>   use_expand_iuses = {}
> + if eapi_attrs.exports_USE_EXPAND_variables:
> + for k in use_expand_split:
> + use_expand_iuses[k] = set()
>   for x in portage_iuse:
>   x_split = x.split('_')
>   if len(x_split) == 1:

After some thinking, I'll prepare another patch that applies the change
to all EAPIs. The behavior for earlier EAPIs is implementation-defined
by PMS and having it inconsistent will only confuse users.

-- 
Best regards,
Michał Górny



pgpwxUpygWeHZ.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] new developers' keyword requests

[Daniel Campbell]

On 05/20/2016 09:47 PM, Matt Turner wrote:
> On Thu, May 19, 2016 at 6:36 PM, Daniel Campbell  wrote:
>> To make sure I understand what you're getting at, are you saying some
>> devs get on board and then request to add keywords to packages that they
>> already maintain?
> 
> No, you've misunderstood.
> 
> He's saying people add new packages and then speculatively add
> keywords for a bunch of architectures that they haven't tested. This
> causes unnecessary packages to be keyworded on archs that don't want
> them and can hardly afford the extra load.
> 
> The appropriate thing to do when adding a new package is to add only
> keywords you can test and maintain (likely just ~amd64), and then file
> a keyword request to ask arch teams to keyword the package if
> appropriate, which leaves the choice to them.
> 

Ah, I see. In that case I'm in full agreement. We're taught during the
mentoring/quizzing process that we don't keyword what we haven't tested.
That's one of the most basic "rules".

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature