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

[Michał Górny]

On Wed, 18 May 2016 23:35:18 +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 | 220 
> 
>  1 file changed, 220 insertions(+)
>  create mode 100644 eclass/rebar.eclass
> 
> diff --git a/eclass/rebar.eclass b/eclass/rebar.eclass
> new file mode 100644
> index 000..e1ac52f
> --- /dev/null
> +++ b/eclass/rebar.eclass
> @@ -0,0 +1,220 @@
> +# 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)
> + die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
> + ;;
> + 5|6)
> + ;;
> + *)
> + die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
> + ;;
> +esac
> +
> +[[ ${EAPI} = 5 ]] && inherit eutils
> +
> +EXPORT_FUNCTIONS src_prepare src_compile src_install
> +
> +RDEPEND="dev-lang/erlang"
> +DEPEND="${RDEPEND}
> + dev-util/rebar"
> +
> +# @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"

Missing multilib inherit for EAPI 5.

> +}
> +
> +# @VARIABLE: ERL_LIBS
> +# @DESCRIPTION:
> +# Full path with EPREFIX to Erlang lib directory. Some rebar scripts expect 
> it.
> +export ERL_LIBS="${EPREFIX}$(get_erl_libs)"

I think calling get_libdir in global scope is forbidden. You should
really export this somewhere in phase function.

> +
> +# @FUNCTION: _find_dep_version

Namespace it, please. Just in case.

> +# @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.
> +_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}-}"
> + return 0
> + fi
> + done
> + popd >/dev/null

|| die

> +
> + return 1
> +}
> +
> +# @FUNCTION: eawk
> +# @USAGE:  
> +# @DESCRIPTION:
> +# Edit file  in place with awk. Pass all arguments following  to
> +# awk.
> +eawk() {
> + local f="$1"; shift
> + local tmpf="$(emktemp)"

Missing eutils inherit for EAPI 6.

> +
> + cat "${f}" >"${tmpf}" || return 1
> + awk "$@" "${tmpf}" >"${f}"
> +}
> +
> +# @FUNCTION: erebar
> +# @USAGE: 
> +# @DESCRIPTION:
> +# Run rebar with verbose flag. Die on failure.
> +erebar() {
> + debug-print-function ${FUNCNAME} "${@}"
> +
> + rebar -v skip_deps=true "$1" || die "rebar $1 failed"
> +}

Any reason it doesn't pass all the parameters? This inconsistency with
emake etc. could be mildly confusing, esp. that you don't check for
wrong argc.

> +
> +# @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.
> +#
> +#  is optional. Default is 'rebar.config'.

Is it likely that you would be passing different values to it? Maybe it
would be reasonable to make this an eclass variable.

> +#
> +# The function dies on failure.
> +rebar_fix_include_path() {
> + debug-print-function ${FUNCNAME} "${@}"
> +
> + local pn="$1"
> + local rebar_config="${2:-rebar.config}"
> + local erl_libs="${EPREFIX}$(get_erl_libs)"
> + local pv="$(_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 

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

[Göktürk Yüksek]

Jeroen Roovers:
> On Wed, 18 May 2016 19:31:38 -0400
> Göktürk Yüksek  wrote:
> 
>> There could be some performance implications. cat will usually do
>> slow, buffered I/O. cp tries to be smarter with allocation, i.e. it
>> may take advantage of the btrfs specific clone to do a O(1) copy.
> 
> Really? We're talking about editing streams of usually a couple of
> kilobytes and performance is what you're worried about? Because of
> not using one particular filesystem maybe? Really?
> 
> 
I wasn't against the use of redirection, just wondering if there was a
reason to prefer that over cp. To me, an extra dup2() in redirection
seems useless. You can also argue that an extra syscall() has no visible
impact and I wouldn't object. cp should work as efficient as shell
redirection and potentially better in some cases. Sure, it won't make a
noticeable difference with such small files.

>  jer
> 

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

[Jeroen Roovers]

On Wed, 18 May 2016 19:31:38 -0400
Göktürk Yüksek  wrote:

> There could be some performance implications. cat will usually do
> slow, buffered I/O. cp tries to be smarter with allocation, i.e. it
> may take advantage of the btrfs specific clone to do a O(1) copy.

Really? We're talking about editing streams of usually a couple of
kilobytes and performance is what you're worried about? Because of
not using one particular filesystem maybe? Really?


 jer

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

[Peter Stuge]

Cool!

aide...@gentoo.org wrote:
> +_find_dep_version() {
> + local pn="$1"
> + local p
> +
> + pushd "${EPREFIX}$(get_erl_libs)" >/dev/null
> + for p in ${pn} ${pn}-*; do
> + if [[ -d ${p} ]]; then
> + echo "${p#${pn}-}"
> + return 0

No popd on success?

> + fi
> + done
> + popd >/dev/null
> +
> + return 1
> +}



> +# @FUNCTION: eawk
> +# @USAGE:  
> +# @DESCRIPTION:
> +# Edit file  in place with awk. Pass all arguments following  to
> +# awk.
> +eawk() {
> + local f="$1"; shift
> + local tmpf="$(emktemp)"
> +
> + cat "${f}" >"${tmpf}" || return 1
> + awk "$@" "${tmpf}" >"${f}"
> +}

Wouldn't it be nicer to cut cat, awk > $tmpf && mv $tmpf $f ?


//Peter

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

[Göktürk Yüksek]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Amadeusz Żołnowski:
> Göktürk Yüksek  writes:
>>> +   cat "${f}" >"${tmpf}" || return 1
>> Why shell redirection with cat instead of cp? both are in
>> coreutils.
> 
> I thought cp could overwrite file mode of already existing tmp
> file, but actually it doesn't, so cp can be here as well. Is there
> actual benefit of using cp here?
> 
There could be some performance implications. cat will usually do
slow, buffered I/O. cp tries to be smarter with allocation, i.e. it
may take advantage of the btrfs specific clone to do a O(1) copy.

>> Also, wouldn't the absence of 'die' cause silent breakages?
> 
> I want to caller decide whether die or not and what error messge
> to give.
> 
Maybe that should be part of the documentation. People are more likely
to assume that it will die on its own, I think. Is there a case in
which you would not want to die?

> Cheers,
> 

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJXPPtVAAoJEIT4AuXAiM4zhX4H+gNivSvNvQzf3tsjmbVatGWB
DLIvIxUY7h79c0YDTXnaU+4LLf7CvED26XT9QNWp297OfNpsXKWGTR5GbdG+w0ab
SR490l9Uh/qn8HBKvh1hmPTEyeRHXm0ZoQ6/jrgwlz7ehSawQlzGRUPqFOHj88Fc
qwWhKk1p2fc7TUnRO0SUY/xcRyZeEyUqEG3ueVYfPlTo10rC5+B20IFjnO09vwbT
INV27KHqjLnpRT4xGWvCyCiEfw6DDypxZ/PKfr4c7omHF8OF+5GGnf+FFZ8UJFkt
93TVIPDeUC9XeAsmqirgN5LuYWsNNUwTEdiDfjglLrTb6OgXA0eIIwXsGH/G3d4=
=J3uT
-END PGP SIGNATURE-

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

[Amadeusz Żołnowski]

Göktürk Yüksek  writes:
>> +cat "${f}" >"${tmpf}" || return 1
> Why shell redirection with cat instead of cp? both are in coreutils.

I thought cp could overwrite file mode of already existing tmp file, but
actually it doesn't, so cp can be here as well. Is there actual benefit
of using cp here?

> Also, wouldn't the absence of 'die' cause silent breakages?

I want to caller decide whether die or not and what error messge to
give.

Cheers,

-- 
Amadeusz Żołnowski


signature.asc
Description: PGP signature

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

[Robin H. Johnson]

On Wed, May 18, 2016 at 10:25:02PM +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.
NAK.

1.
If your AWK command has an error, then this clobbers the file, a better
variant, with die, would be:
awk "$@" "$f" >"${tmpf}" || die "awk failed..."
cp -f "${tmpf}" "$f" || die "copy back failed"

> # @USAGE:  
This calling format is also a problem if they intended to pass multiple
files to the command, or if they do so accidentally. 

Eg, an unprotected glob in the first argument, eg:
eawk foo* '/foobar/{$1="x"; print $0}'

If foo1 and foo2 existed, this would be considered as:
awk foo2 /foobar/{$1="x"; print $0}' foo1

which really will NOT have the desired effect.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[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 | 220 
 1 file changed, 220 insertions(+)
 create mode 100644 eclass/rebar.eclass

diff --git a/eclass/rebar.eclass b/eclass/rebar.eclass
new file mode 100644
index 000..e1ac52f
--- /dev/null
+++ b/eclass/rebar.eclass
@@ -0,0 +1,220 @@
+# 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)
+   die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
+   ;;
+   5|6)
+   ;;
+   *)
+   die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
+   ;;
+esac
+
+[[ ${EAPI} = 5 ]] && inherit eutils
+
+EXPORT_FUNCTIONS src_prepare src_compile src_install
+
+RDEPEND="dev-lang/erlang"
+DEPEND="${RDEPEND}
+   dev-util/rebar"
+
+# @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"
+}
+
+# @VARIABLE: ERL_LIBS
+# @DESCRIPTION:
+# Full path with EPREFIX to Erlang lib directory. Some rebar scripts expect it.
+export ERL_LIBS="${EPREFIX}$(get_erl_libs)"
+
+# @FUNCTION: _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.
+_find_dep_version() {
+   local pn="$1"
+   local p
+
+   pushd "${EPREFIX}$(get_erl_libs)" >/dev/null
+   for p in ${pn} ${pn}-*; do
+   if [[ -d ${p} ]]; then
+   echo "${p#${pn}-}"
+   return 0
+   fi
+   done
+   popd >/dev/null
+
+   return 1
+}
+
+# @FUNCTION: eawk
+# @USAGE:  
+# @DESCRIPTION:
+# Edit file  in place with awk. Pass all arguments following  to
+# awk.
+eawk() {
+   local f="$1"; shift
+   local tmpf="$(emktemp)"
+
+   cat "${f}" >"${tmpf}" || return 1
+   awk "$@" "${tmpf}" >"${f}"
+}
+
+# @FUNCTION: erebar
+# @USAGE: 
+# @DESCRIPTION:
+# Run rebar with verbose flag. Die on failure.
+erebar() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   rebar -v skip_deps=true "$1" || die "rebar $1 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.
+#
+#  is optional. Default is 'rebar.config'.
+#
+# The function dies on failure.
+rebar_fix_include_path() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local pn="$1"
+   local rebar_config="${2:-rebar.config}"
+   local erl_libs="${EPREFIX}$(get_erl_libs)"
+   local pv="$(_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
+# @USAGE: []
+# @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.
+#
+#  is optional. Default is 'rebar.config'.
+#
+# The function dies on failure.
+rebar_remove_deps() {
+   debug-print-function ${FUNCNAME} "${@}"
+
+   local rebar_config="${1:-rebar.config}"
+
+   mkdir -p "${S}/deps" && :>"${S}/deps/.got" && :>"${S}/deps/.built" || 
die
+   eawk 

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

[Göktürk Yüksek]

aide...@gentoo.org:
> 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.
> ---
>  eclass/eutils.eclass | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
> index dbedffe..e331f1b 100644
> --- a/eclass/eutils.eclass
> +++ b/eclass/eutils.eclass
> @@ -20,6 +20,19 @@ _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)"
> +
> + cat "${f}" >"${tmpf}" || return 1
Why shell redirection with cat instead of cp? both are in coreutils.
Also, wouldn't the absence of 'die' cause silent breakages?

> + awk "$@" "${tmpf}" >"${f}"
> +}
> +
>  # @FUNCTION: eqawarn
>  # @USAGE: [message]
>  # @DESCRIPTION:
> 

[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.
---
 eclass/eutils.eclass | 13 +
 1 file changed, 13 insertions(+)

diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
index dbedffe..e331f1b 100644
--- a/eclass/eutils.eclass
+++ b/eclass/eutils.eclass
@@ -20,6 +20,19 @@ _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)"
+
+   cat "${f}" >"${tmpf}" || return 1
+   awk "$@" "${tmpf}" >"${f}"
+}
+
 # @FUNCTION: eqawarn
 # @USAGE: [message]
 # @DESCRIPTION:
-- 
2.8.2

Re: [gentoo-dev] [RFC] Enable CMAKE_WARN_UNUSED_CLI by default in cmake-utils for EAPI>=6

[Maciej Mrozowski]

On Wednesday 18 of May 2016 09:22:53 Andrew Savchenko wrote:
> On Mon, 02 May 2016 18:06:44 +0200 Maciej Mrozowski wrote:
> > Hello,
> > 
> > General advise: do not convert ebuilds inheriting cmake-utils to EAPI 6
> > unless you know what you are doing (you are fully aware of eclass
> > behaviour removed with https://bugs.gentoo.org/show_bug.cgi?id=514384).
> > 
> > Background:
> > 
> > Pre EAPI-6 cmake-utils.eclass contained certain feature to mitigate CMake
> > variable case changes done by upstream.
> > This feature was explicitly removed with
> > https://bugs.gentoo.org/show_bug.cgi?id=514384 and no alternative was
> > proposed.
> > It opened new area of possible ebuild regression bugs when switching to
> > EAPI-6 for ebuilds inheriting cmake-utils.eclass.
> > 
> > Unfortunately there is common misconception, also among developers, that
> > it's sufficient to simply replace "${cmake-utils_use_with foo)" with
> > "-DWITH_foo=ON" etc.
> > This is MOST OF THE TIME not the case.
> > When converting cmake-utils ebuild to EAPI>=6, one needs to consult
> > CMakeLists.txt wrt case each variable is written with since CMake is case-
> > sensitive and WITH_FOO != WITH_foo != WITH_Foo.
> > 
> > Proposal:
> > 
> > CMake allows warning about unused CMake variables passed by CLI. Since
> > this is how Gentoo passes ebuild configuration options, it's proposed to
> > enable this feature.
> > Unfortunately it won't fail compilation but at least it gives a chance to
> > spot case mismatch when reading build output.
> > 
> > Future thoughts:
> > 
> > For better damage control it's technically possible to extend configure
> > phase of cmake-utuls eclass to check mycmakeargs against parsed package
> > buildsystem but this might not be very reliable.
> 
> For me the real confusion was from this line:
> 
> die "${FUNCNAME[1]} is banned in EAPI 6 and later: use
> -D$1${arg}=\"\$(usex $2)\" instead"
> 
> It recommends to use ${arg} without any warning about case, so when I just
> copied what it recommends: -DWITH_nls="$(usex nls)", I had a nice surprise
> and fun debugging.

Ah, there you go..

@kensington
Come on, man, you should have known better.

Invalid suggestion removed. Thanks for noticing.
I prefer to have developers figure out the right EAPI-6 migration path 
themselves rather than blindly relying on suggestions:

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index 427c13f..5958230 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -161,7 +161,7 @@ _cmake_use_me_now() {
local arg=$2
[[ ! -z $3 ]] && arg=$3
 
-   [[ ${EAPI} == [2345] ]] || die "${FUNCNAME[1]} is banned in EAPI 6 and 
later: use -D$1${arg}=\"\$(usex $2)\" instead"
+   [[ ${EAPI} == [2345] ]] || die "${FUNCNAME[1]} is banned in EAPI 6 and 
later"
 
local uper capitalised x
[[ -z $2 ]] && die "cmake-utils_use-$1  []"
@@ -184,7 +184,7 @@ _cmake_use_me_now_inverted() {
[[ ! -z $3 ]] && arg=$3
 
if [[ ${EAPI} != [2345] && "${FUNCNAME[1]}" != cmake-
utils_use_find_package ]] ; then
-   die "${FUNCNAME[1]} is banned in EAPI 6 and later: use -
D$1${arg}=\"\$(usex $2)\" instead"
+   die "${FUNCNAME[1]} is banned in EAPI 6 and later"
fi
 
local uper capitalised x

regards
MM

signature.asc
Description: This is a digitally signed message part.

[gentoo-portage-dev] Re: [PATCH v2] Change how the tmp file for the commit msg is made (bug 571546)

[Zac Medico]

On 05/18/2016 11:57 AM, Doug Goldstein wrote:
> On 5/18/16 11:38 AM, Zac Medico wrote:
>> On Tue, May 17, 2016 at 11:43 PM, Alexander Berntsen
>>  wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA512
>>>
>>> On 17/05/16 15:36, Doug Goldstein wrote:
 ping? I believe I covered all the review items but I see this is
 not in master yet. Is there anything further you need me to do?
>>> It seems you are replying to a thread with a second version of your
>>> patch. I don't have the initial email to this thread. I don't know
>>> what fucked up, or where. Could you resend the patch? Sorry about this.
>>
>> This continues a thread that originally started on the dev-portage
>> alias, but I don't see a mail PATCH v2 anywhere either.
>>
>> Thanks,
>> Zac
>>
> 
> I sent it to gentoo-portage-dev@lists.gentoo.org as requested. I can
> resend it.
> 

It was probably during a certain window of time a couple months back
when no mails were reaching the list.
-- 
Thanks,
Zac

Re: [gentoo-portage-dev] [PATCH] news.py: Check only for major version when parsing

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 18/05/16 17:46, Zac Medico wrote:
> not fnmatch.fnmatch(format_match.group(1), '1.*')):
Wait, why "not"?

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXPKCxAAoJENQqWdRUGk8B7QAP/ixWgI2RU1CBXNLe+77mgxKk
rVtetbPmXyjiWgrkQvayLOVHF5JO4sh7PiH4Qpo75VhFKr48/GuIfYzt3q6b8gNn
GwP0fI0zc/fBoQYaHXI/qjyp+uCcEQAhT2yuvRFat7wRPTgSJKcbk/vsA6Eoof4c
rin3uWiWI5P+vNI7Kbmv7NNFshQ9Ak4J80AZmc+h/H0asj7Va7s/FyhlnXciL4Xh
H4H8SklefZoN+m8gPo90o6ny5PLIlDAtrdsESKXtKqKFX4OFyjkfRn3I7M+Gplki
+zrxDKGK2fYNMsgECS003cGEtnlkF2d9DTUAakCQJadKLPZXJ8kZnissBcmIqwyg
dH+1IhFUHAeBghEfan86x9SEtJ0HIEYEX/zHrknCZDLRtk5V8grlyWjA3bRYtfka
CbX6J4F0hgDPao4WHkUYp6I6NaDJTA9XwyNkX0E+GObCu9GvvdMy87DOFVVkEua9
Hlq6XAyTnMRZ3doh8eS2enDMul1qlng742BQ8D9egc49GxSl6eIZwELDS0QsTkQN
I+KNIB3ktNnxhh4FX+Gp4HPXEtsXNbXzqfNp6AbYcWh/lbH5jVZOYwuU+sJ/Ky/j
76hdj9BmNsncsPvmxxslBjJHq8SKIs3RKs+9HukFN/+zbSpGvkhi5BQQ3Tk+tPZK
Ju6X2kT2Hu3s77Wt6XjX
=t647
-END PGP SIGNATURE-

Re: [gentoo-portage-dev] [PATCH] news.py: Check only for major version when parsing

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 18/05/16 17:46, Zac Medico wrote:
> if (format_match is not None and not
> fnmatch.fnmatch(format_match.group(1), '1.*')):
Yes! Sorry! I had made that change, but then forgotten to stage it. So
sorry. It's been hell of a day, so it just slipped past me. I'll get
right to it.

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXPJ7lAAoJENQqWdRUGk8BK5UQAIjkJMxmoBi2uKGWHNpZ6gvg
X2km6wtokpowTtrTNVRD5zjtJeyhKPa/jkp5EVoka6GbW8Ap/9ykUSR36xxscQ5R
HxWnpP6OPrPS59wpXU+gTRLOwEhLE9gP1WEQFHPCnPwmIasYXZl4BXK/IOU3rblc
PymEa+VvTU2Kg0EdLsnqQ4rHvkBngwykByC64zM3eL3ZoJoO8tmZ8cRByObCYWk/
SJkLp6F/WdWJSmwldS/e+HhgAn0Y7DEKpv3NYpKT3osv+ga4CXaxalToNy+pmwIj
kAC7EqMREBEOAumcitTPKxKtUZhkxm/SJC/+e0BWAvOAWMcP9+pxRmMwTx8wrgym
6zN53g+MFSqYMxwm5Xvy+vIBflfXBiRYFNxs/hGfDLCh5270pHnvYH4V80lS8wQX
InobYnpuwQcvJWN5CiT0kY8fYTgfCE28AIBgPSHO62+Fbmc60v0Fbh7X8KDv1aI7
TPKCldsFuIXj5X3PefGM8/aUq4DE94slGtNSiVrl1c+KKfKRCY6g6XzjYNm2m1i6
cwXldoofl973bNAyV9m3ACntHQXV/Q+/h4imC2lS08Yhb6s8lmsSrozEQqoYbgPN
0c1aFF+maNjDZKH0oDDXhLW2JeKScEan6lyotppiWKImJhqgq+oWVtg3asBx426k
CKOQJdfbZtI0ICBLL5eY
=1ZKx
-END PGP SIGNATURE-

[gentoo-portage-dev] Re: [PATCH v2] Change how the tmp file for the commit msg is made (bug 571546)

[Zac Medico]

On Tue, May 17, 2016 at 11:43 PM, Alexander Berntsen
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 17/05/16 15:36, Doug Goldstein wrote:
>> ping? I believe I covered all the review items but I see this is
>> not in master yet. Is there anything further you need me to do?
> It seems you are replying to a thread with a second version of your
> patch. I don't have the initial email to this thread. I don't know
> what fucked up, or where. Could you resend the patch? Sorry about this.

This continues a thread that originally started on the dev-portage
alias, but I don't see a mail PATCH v2 anywhere either.

Thanks,
Zac

Re: [gentoo-portage-dev] [PATCH] pym/portage/util/locale.py: add a C module to check locale

[Anthony G. Basile]

On 5/18/16 10:51 AM, Anthony G. Basile wrote:
> On 5/18/16 10:26 AM, Brian Dolbec wrote:
>> On Wed, 18 May 2016 06:08:20 -0400
>> "Anthony G. Basile"  wrote:
>>
>>> On 5/18/16 2:50 AM, Alexander Berntsen wrote:
 On 17/05/16 14:47, Anthony G. Basile wrote:  
> Since this is the first python module written in C included in
> portage, as a side effect, we introduce the machinary for future
> modules in setup.py.  
 Split it into two commits.
   
>>> Read the code, you really can't.
>>>
>>
>> I think he means the setup.py change that adds the extension
>> capability, then add the locale changes and new module.
>> That seems like a logical split to me.
>>
> 
> Actually its got nothing to do with the module.  Its an independent bug.
>  Here's how you can reproduce:
> 
> 1. edit /etc/locale.gen and uncomment all the locales
> 
> 2. run locale-gen
> 
> 3. use eselect locale to choose 'turkish'
> 
> 4. use eselect python to choose 2.7
> 
> 5. emerge =sys-apps/gradm or anything
> 
> No patch nothing.  You'll hit it with 2.2.28 and above.
> 
> Brian, can you see if you hit it there.
> 

oops sorry I replied to the wrong email.  I can do that split.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: [gentoo-portage-dev] [PATCH] pym/portage/util/locale.py: add a C module to check locale

[Anthony G. Basile]

On 5/18/16 10:26 AM, Brian Dolbec wrote:
> On Wed, 18 May 2016 06:08:20 -0400
> "Anthony G. Basile"  wrote:
> 
>> On 5/18/16 2:50 AM, Alexander Berntsen wrote:
>>> On 17/05/16 14:47, Anthony G. Basile wrote:  
 Since this is the first python module written in C included in
 portage, as a side effect, we introduce the machinary for future
 modules in setup.py.  
>>> Split it into two commits.
>>>   
>> Read the code, you really can't.
>>
> 
> I think he means the setup.py change that adds the extension
> capability, then add the locale changes and new module.
> That seems like a logical split to me.
> 

Actually its got nothing to do with the module.  Its an independent bug.
 Here's how you can reproduce:

1. edit /etc/locale.gen and uncomment all the locales

2. run locale-gen

3. use eselect locale to choose 'turkish'

4. use eselect python to choose 2.7

5. emerge =sys-apps/gradm or anything

No patch nothing.  You'll hit it with 2.2.28 and above.

Brian, can you see if you hit it there.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: [gentoo-portage-dev] [PATCH] pym/portage/util/locale.py: add a C module to check locale

[Anthony G. Basile]

On 5/17/16 9:38 AM, Brian Dolbec wrote:
> 
> Overall I like it, but I'll let others review the actual code
> implementation since I'm not an experienced "C" coder. In 30
> years, I never did more than hello world a few times in C.  And the
> pascal coding I did in College is more like python than c.
> 
> 

I updated the patch and its working fine with python3.4 but with 2.7 I'm
hitting the following error which makes no sense to me.  What's even
worse, is that I can manually import the module from a python2.7 shell
and it works as intended, but it doesn't in the context of portage.

As part of my debugging I stripped the module down to what amounts to a
"hello world" and I still hit this.  So *any* python module written in C
is going to have this issue.

Anyone have a clue?


Traceback (most recent call last):
  File "/usr/lib/python-exec/python2.7/emerge", line 50, in 
retval = emerge_main()
  File "/usr/lib64/python2.7/site-packages/_emerge/main.py", line 1157,
in emerge_main
action=myaction, args=myfiles, opts=myopts)
  File
"/usr/lib64/python2.7/site-packages/portage/proxy/objectproxy.py", line
31, in __call__
return result(*args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/_emerge/actions.py", line
2387, in load_emerge_config
root_trees["root_config"] = RootConfig(settings, root_trees, setconfig)
  File "/usr/lib64/python2.7/site-packages/_emerge/RootConfig.py", line
27, in __init__
self.sets = self.setconfig.getSets()
  File "/usr/lib64/python2.7/site-packages/portage/_sets/__init__.py",
line 284, in getSets
self._parse()
  File "/usr/lib64/python2.7/site-packages/portage/_sets/__init__.py",
line 230, in _parse
optdict[oname] = parser.get(sname, oname)
  File "/usr/lib64/python2.7/ConfigParser.py", line 623, in get
return self._interpolate(section, option, value, d)
  File "/usr/lib64/python2.7/ConfigParser.py", line 691, in _interpolate
self._interpolate_some(option, L, rawval, section, vars, 1)
  File "/usr/lib64/python2.7/ConfigParser.py", line 723, in
_interpolate_some
option, section, rest, var)
InterpolationMissingOptionError: Bad value substitution:
section: [usersets]
option : directory
key: portage_configroot
rawval : etc/portage/sets




-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: [gentoo-portage-dev] [PATCH] pym/portage/util/locale.py: add a C module to check locale

[Brian Dolbec]

On Wed, 18 May 2016 06:08:20 -0400
"Anthony G. Basile"  wrote:

> On 5/18/16 2:50 AM, Alexander Berntsen wrote:
> > On 17/05/16 14:47, Anthony G. Basile wrote:  
> >> Since this is the first python module written in C included in
> >> portage, as a side effect, we introduce the machinary for future
> >> modules in setup.py.  
> > Split it into two commits.
> >   
> Read the code, you really can't.
> 

I think he means the setup.py change that adds the extension
capability, then add the locale changes and new module.
That seems like a logical split to me.

-- 
Brian Dolbec 

[gentoo-dev] Package up for grabs: sys-boot/gummiboot

[Michał Górny]

I'm no longer willing to maintain sys-boot/gummiboot and this makes it
maintainer-needed. The package is no longer maintained upstream,
and has been merged into systemd. It seems that there are still people
using it without systemd though, so I'm not going to lastrite it
myself, and prefer getting a new maintainer for it.

-- 
Best regards,
Michał Górny



pgpnVX_bQMad0.pgp
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH] pym/portage/util/locale.py: add a C module to check locale

[Anthony G. Basile]

On 5/18/16 2:50 AM, Alexander Berntsen wrote:
> On 17/05/16 14:47, Anthony G. Basile wrote:
>> Since this is the first python module written in C included in
>> portage, as a side effect, we introduce the machinary for future
>> modules in setup.py.
> Split it into two commits.
> 
Read the code, you really can't.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

[gentoo-portage-dev] [PATCH] news.py: Check only for major version when parsing

[Alexander Berntsen]

Only check the major version of news items, as GLEP 42 specifies an
upgrade path for them. Future revisions to news item formats may yield
minor number increments. GLEP 42 further ensures that only
forwards-compatible changes may incur, as incompatible changes demand a
major version increment.

Suggested-by:  Ulrich Müller  
Signed-off-by: Alexander Berntsen 
---
 pym/portage/news.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pym/portage/news.py b/pym/portage/news.py
index 784ba70..f52d96e 100644
--- a/pym/portage/news.py
+++ b/pym/portage/news.py
@@ -270,7 +270,7 @@ class NewsItem(object):
# Optimization to ignore regex matchines on lines that
# will never match
format_match = _formatRE.match(line)
-   if format_match is not None and format_match.group(1) 
!= '1.0':
+   if format_match is not None and format_match.group(1) 
!= '1.*':
invalids.append((i + 1, line.rstrip('\n')))
break
if not line.startswith('D'):
-- 
2.7.3

[gentoo-dev] Re: Proposal for changes for the next EAPI version

[Duncan]

Ciaran McCreesh posted on Tue, 17 May 2016 12:29:36 +0100 as excerpted:

> On Tue, 17 May 2016 07:26:03 -0400 Michael Orlitzky 
> wrote:
>> We already have "emerge --config" which is expected to be run after the
>> install process has completed, so I don't think that this is too much
>> of a stretch. Maybe call the phase "pkg_test" analogous to "pkg_config"
>> and in contrast to "src_test" which runs within the working directory.
>> Then "emerge --test" could run it.
> 
> For various technical reasons to do with the spec and package manglers
> sometimes using phase function names with the src_ or pkg_ stripped off,
> calling it that would be a huge pain.

What about something like gentoo_test, or more generically, distro_test?

That would also emphasize the difference between distro-level 
functionality and integration testing (which if I'm reading correctly is 
the proposal here) and upstream-level testing, via src_test.

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

[gentoo-dev] Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run

[Austin English]

On 05/03/2016 11:27 PM, Austin English wrote:
> Hi there,
>
> I've been working on the transition from #!/sbin/runscript to
> #!/sbin/openrc-run [1], by starting on the maintainer-needed packages.
> That's done (aside from some stabilizations needed, but I'll deal with that
> latter). The trouble is that there are roughly 700 packages that need to
> be updated, and that's an insane number of bugs to file.
>
> So, instead, I'm going to give developers to two weeks to update their
> initscripts or ask me not to touch it. On/after 2016/05/18, I'll update
> initscripts/copyrights, but will leave revbumping to maintainer's discretion.
>
> Thanks,
> Austin
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=573846

I've updated everything in the tree to use #!/sbin/openrc-run. The
/sbin/runscript symlink still remains for now, don't worry. I plan to
add checks in repoman/qa checks in the near future to prevent the
deprecated shebang from creeping back in.

Maintainers, please revbump your packages at your discretion.

Thanks!
Austin



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH] pym/portage/util/locale.py: add a C module to check locale

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 17/05/16 14:47, Anthony G. Basile wrote:
> Since this is the first python module written in C included in
> portage, as a side effect, we introduce the machinary for future
> modules in setup.py.
Split it into two commits.
- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXPBCjAAoJENQqWdRUGk8BIn8QALh3Aa/VaDGQwZNCxD9r65kW
BqK0qmGnowQZ97DqB1HmtkOOqyrn3G1RdlyossNddfYWdhKFnHxgKSP0oypau1tJ
XYwHPcF4qPbe/tBwVAtTwE2cpe65LXqAfi0wGC6aZJV49vy9CQbXp7LV6AqX/ucG
rnA3qMXQYeATqiZrzU9ZKSB5e0t4/ga43grwGWLeF8Afdwmf/snpnOOTtOUTixyo
+UT8r/O9ix+VpnNHr8Pticmvn3wW848+0eeN/GQnG/zicgZVPYpYsjY5KegR/UDE
Ux1kF2ngenH3aCtRp3dy4X7jzE9ogW2cHnd0JoYjS5YI4DyvOxA9VJamXuwX2TAJ
dKPNEJFTUMqUEF9C35EW6XLPyUMtNf61awjN4uhLPweaJPoHUvB5Fi1VuHx6i88C
DZsckDo+LUpA5pXhmeSkWeWXkrconmJnO06i5h9gq6y8Z4aAYTq7RsP+mPtk/eI8
b0kTDez1z5+Aps+9FosUQqXJCBO3iR6bDU3TKx2n5eOm+sNa7VabqradDArgfxZr
RNjcVpVDpuVCFBZg6kXjx2ghROjjuIagQDywuLC73nxaoPuToypxu5em1c6cEIhy
hSedTXCma9NM4KD8imRw9fMsX6ZUHeaNEhujjCos5jVeR1c+j/XiFxGL4sLPpD8f
wk2Ho+GfdGIS/51LMJ7e
=G9ol
-END PGP SIGNATURE-

Re: [gentoo-dev] Proposal for enhancement to PMS/EAPI7+

[M. J. Everitt]

On 18/05/16 07:43, Michał Górny wrote:
> On Wed, 18 May 2016 04:07:07 +0100
> "M. J. Everitt"  wrote:
>
>> I've just been party to a discussion over in the Proxy Maintainers
>> channel .. and the subject of correct ways to install documentation
>> popped up. It seems to me rather quirky, that there is no middle ground
>> in (for example) EAPI6 to have the default documentation installed per
>> https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-144003r4 , PLUS maybe
>> another folder or file(s). The existing framework ONLY allows *either*
>> /only/ the default documentation *or* an override through the DOCS=
>> variable.
>>
>> My idea thus, was inspired by the simple bash DOCS+= ( ) statement, that
>> would allow you to append files/folders to the installdocs list,
>> assuming that DOCS was pre-populated with an existing set of files.
>> Obviously the status quo is set for EAPI6 and algorithms defined, but
>> wondered if it could be considered for a future update/improvement cycle?!
> How is this going to work? In order to pre-populate it, you need to
> know the list of files. And the list of files isn't known until
> src_install(). In fact, with the current behavior it's not even known
> before einstalldocs is actually called, and changing that could break
> stuff.
>
At present the DOCS to be installed in the default function are
hard-coded into the PMS in 'einstalldocs' .. not exactly very good if
you decided later to change it?!



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH] dblink: add locks for parallel-install with blockers (bug 576888)

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 17/05/16 15:48, Brian Dolbec wrote:
> Alexander, with 2.3.0_rc1-r1 released, I think we can re-open
> portage code for more patches before the official 2.3.0 release.
> We now know the split install is working, it only had the one
> portage bug from the split.
Great! Let's resume normal working conditions then.

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXPA97AAoJENQqWdRUGk8BMYoQALmth11ACOgrvJgXLxWPkjGS
3aUIEV8D7vSdVDfkUB2CdN763ocmBC3xSkQXKfYx0DtnFmQcIJCY+tkvpaVLN6m3
VX53pCYVwVeLOZhmRzpgMXN7GdvOn5ldYMvorjKt2eU8WUrg3lboBLregvk4So0W
9OLpgEdFX9KaNaMFfU0TXzi3DopmOiS9juHiMGwZBd9D8mdZlgi94hK0pBRvqnmu
UwesoquKoItEtLikjnLcvnz14RdQ1NtBifDeoqdOSV2QODxks0LBt5sKHFLDor9Q
l3fA6FxMm62d586pd5Lw3UbhSe8/FOZSSBUpHCUcwz6jH5AjC7RQqsKEapqraqUr
eWQdz4G+qY5+0BVrd6TaPZ34m66A/7eTpj5z/np+hjC7vBhxXTSsty7B9epSukiV
YGEg19pW6xV27+o1IVUXzAgLR6iKm9OGDtI0X2cr1g5MBUToKxPjHkgzITmWifIJ
65+K3tTx0W/iEIMzqd/PqPu9pSavkGSRIko5XUPrTe5CqK4QrZ4tUPWgpZ9bKnA0
oHkigK6d2fWNMN1idlvzaOmkQuq1HkrwM/zKugCI4tUjgFKb5Q0/s5noHOl+ZRRK
prdnObItii0Yz9GgKmlSEt5W58VQ4N+n0WfpHOsT64Tl3MLc9WuYTL/urNkEPmXu
OBqZriulxLJjf9MG/3LX
=l7W4
-END PGP SIGNATURE-

Re: [gentoo-portage-dev] [PATCH] dblink: add locks for parallel-install with blockers (bug 576888)

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 16/05/16 21:20, Zac Medico wrote:
> Can we merge this now?
Yes!

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXPA9VAAoJENQqWdRUGk8Bn2gP/0/HFsTovWmfkoletX2+UzpU
45BZi2ae9O78TqAX9hMexd5zCSpiQydpIWi4ZVfYHeNZSTMNwixEutPWYCz1XjzX
VkMDKL9PGweWqMBL/oShid3FQ2NsUtUdI/pP2aM2jFhb3m+cmcT1m/zTqgArYh0l
TCMhKM5ky/GEQGCX6NMB9fFjdQdt/bofefeBVFChEl/wWDP7AdpQ5Fc+Kq7Wo+3K
XVwKeQ1J/6J0WqBtlvvYhGNkVf0QKNh20ki4JUSpUfvAEfXXgtEV1vO8A9hcK9X9
zJrX39nEbr1oLYbERSipW6XfhdwRlWee6X8CZOnSYYWjmdvG1XVFtLHCFvOV9wQs
tYa/E+f2VkpgOct0KTR9hnnDg/+W+wEl+Edy9UxH1IWNHOiaNzsklVIxZTBzHded
ndv95VOw4akcfB49OR2Er6R7pQ8zhcrq+yoxkIfrPRww7yTghB2/8uZ03NSYFkDl
JkWMs8Y7yXY/PeSlZhwCHliqDuHIgXJOvnOXg3hH1wh+8MlVYmt4w+IFYSk5u9HY
3CDUfev6qsyeSuzLhZxCCSNLW5qejeCp2oAidThujDgHKA02ObzvXkPJeHaWxA22
MunTS9SqpZUoJP8MHxjDH5PUK1ID0EOhFziTJRqKripn+HZqpOoAXQxikF5q/0jl
1Xuydn+5jtveN1+ExOPc
=Ma++
-END PGP SIGNATURE-

Re: [gentoo-dev] Proposal for enhancement to PMS/EAPI7+

[Michał Górny]

On Wed, 18 May 2016 04:07:07 +0100
"M. J. Everitt"  wrote:

> I've just been party to a discussion over in the Proxy Maintainers
> channel .. and the subject of correct ways to install documentation
> popped up. It seems to me rather quirky, that there is no middle ground
> in (for example) EAPI6 to have the default documentation installed per
> https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-144003r4 , PLUS maybe
> another folder or file(s). The existing framework ONLY allows *either*
> /only/ the default documentation *or* an override through the DOCS=
> variable.
> 
> My idea thus, was inspired by the simple bash DOCS+= ( ) statement, that
> would allow you to append files/folders to the installdocs list,
> assuming that DOCS was pre-populated with an existing set of files.
> Obviously the status quo is set for EAPI6 and algorithms defined, but
> wondered if it could be considered for a future update/improvement cycle?!

How is this going to work? In order to pre-populate it, you need to
know the list of files. And the list of files isn't known until
src_install(). In fact, with the current behavior it's not even known
before einstalldocs is actually called, and changing that could break
stuff.

-- 
Best regards,
Michał Górny



pgphWBhjvvOI9.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Proposal for enhancement to PMS/EAPI7+

[Ulrich Mueller]

> On Wed, 18 May 2016, Kent Fredric wrote:

> On 18 May 2016 at 17:40, Ulrich Mueller  wrote:
>> Only two lines. Do you think this is untidy?

> It only becomes untidy where you don't already have a src_install.

> Then it becomes 4 lines.

> 4 lines of which 3 are redundant and simply re-codify existing
> behaviour.

Well, the tradeoff is between adding three lines to a few ebuilds, or
exporting a redundant DOCS variable to _every_ ebuild's environment.

Ulrich


pgp0501thOzf6.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] Enable CMAKE_WARN_UNUSED_CLI by default in cmake-utils for EAPI>=6

[Andrew Savchenko]

On Mon, 02 May 2016 18:06:44 +0200 Maciej Mrozowski wrote:
> Hello,
> 
> General advise: do not convert ebuilds inheriting cmake-utils to EAPI 6 
> unless 
> you know what you are doing (you are fully aware of eclass behaviour removed 
> with https://bugs.gentoo.org/show_bug.cgi?id=514384).
> 
> Background:
> 
> Pre EAPI-6 cmake-utils.eclass contained certain feature to mitigate CMake 
> variable case changes done by upstream.
> This feature was explicitly removed with 
> https://bugs.gentoo.org/show_bug.cgi?id=514384 and no alternative was 
> proposed.
> It opened new area of possible ebuild regression bugs when switching to 
> EAPI-6 
> for ebuilds inheriting cmake-utils.eclass.
> 
> Unfortunately there is common misconception, also among developers, that it's 
> sufficient to simply replace "${cmake-utils_use_with foo)" with 
> "-DWITH_foo=ON" 
> etc.
> This is MOST OF THE TIME not the case.
> When converting cmake-utils ebuild to EAPI>=6, one needs to consult 
> CMakeLists.txt wrt case each variable is written with since CMake is case-
> sensitive and WITH_FOO != WITH_foo != WITH_Foo.
> 
> Proposal:
> 
> CMake allows warning about unused CMake variables passed by CLI. Since this 
> is 
> how Gentoo passes ebuild configuration options, it's proposed to enable this 
> feature.
> Unfortunately it won't fail compilation but at least it gives a chance to 
> spot 
> case mismatch when reading build output.
> 
> Future thoughts:
> 
> For better damage control it's technically possible to extend configure phase 
> of cmake-utuls eclass to check mycmakeargs against parsed package buildsystem 
> but this might not be very reliable.

For me the real confusion was from this line:

die "${FUNCNAME[1]} is banned in EAPI 6 and later: use -D$1${arg}=\"\$(usex 
$2)\" instead"

It recommends to use ${arg} without any warning about case, so when I just
copied what it recommends: -DWITH_nls="$(usex nls)", I had a nice surprise
and fun debugging.

Best regards,
Andrew Savchenko


pgpP7i2a1pk28.pgp
Description: PGP signature