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

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

a distinction without a difference
-mike


signature.asc
Description: Digital signature

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

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

sounds fine
-mike


signature.asc
Description: Digital signature

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

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

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


signature.asc
Description: Digital signature

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

2016-01-20 Thread Rich Freeman 
On Wed, Jan 20, 2016 at 12:34 PM, Mike Frysinger  wrote:
> On 18 Jan 2016 00:57, Joshua Kinard wrote:
>> On 01/17/2016 14:57, Michał Górny wrote:
>> > sys-apps/kexec-tools :
>>
>> Better suited for base-system, maybe?
>>
>> > sys-fs/jfsutils  :
>>
>> Definitely base-system, as xfsprogs is already maintained by them.
>
> sounds fine for both.  generally fs tools probably should live under
> base-system for consistency.

Nothing wrong with consistency, but I'd prefer a package to be placed
under the base-system project because the base-system project members
intend to maintain it.  I don't want to see packages placed into
projects simply because they're similar to other packages in those
projects if it means they'll just be neglected.

I have no idea which is the case here.  If the base-system maintainers
want to maintain these two packages, have at it!  If not, leave it as
maintainer-needed.

-- 
Rich

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

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

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

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


signature.asc
Description: Digital signature

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

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

how about moving those to base-system@ ?

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


signature.asc
Description: Digital signature

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

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

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


signature.asc
Description: Digital signature

Re: [gentoo-dev] Gentoo Dinner@FOSDEM 2016

2016-01-20 Thread Xavier Miller 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi!

There are now 10 attendees. Are there other candidates?
If yes, please suscribe at [1], because I will contact the restaurant
friday.

Kind regards,
Xavier Miller.

Le 13/01/16 10:19, Xavier Miller a écrit :
> Hi!
> 
> The FOSDEM 2016 is very soon (29-31 january) [1], and there will be
> a Gentoo dinner on the saturday evening (30th january).
> 
> Like last year, I will book a place. Therefore, I need to quickly
> now who will attend to this dinner (add you to the list [1]).
> 
> If you have any suggestions for the place, I will be listening
> until tomorrow 14 january. Seems the Thai we chosen was a success,
> I suggest to go there again.
> 
> 
> So, please contact me here, on the forum, or at #gentoo-fosdem.
> 
> Kind regards, Xavier Miller.
> 
> [1] https://wiki.gentoo.org/wiki/FOSDEM_2016
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWn9k2AAoJEOD8dk+NZjCofQcIAMNt6t8/BsBFAMNurXnNnt3k
IA87ksu1hoU31fK/XfOHR+RxDrpYmZEuyjzY7HgcTvxZ5QJ8sTDa6lYosJ5g4bYD
wRb6VtYnN0n+cMEhZQtIM9CS6k8gq1mc+B+HGdQO8DhT9BTpBmgUVcCefrbEa1/v
qz7GLuUuC1fAaE96jURo5wXDDIHVoKjePcJW7at5bqtzX8NySXLHErOWHmnCTjVY
r2vo8pIC08DWEFZl2mpE1lqy6bzJQM2nADL7u1U1RW9XzVpATZAiOFwzp9ahH1vM
Hzr2iwGSZUYDmkeW0meyQo0UUK3Mlx5cgCfgZdhe60gJnyCmOI6g1OU3O1xeJ0M=
=VhP8
-END PGP SIGNATURE-

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

2016-01-20 Thread Duncan 
Mike Frysinger posted on Wed, 20 Jan 2016 13:40:04 -0500 as excerpted:

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

Umm, you mean project, right?  Because the whole discussion here is part 
of getting rid of herds.  =:^)

-- 
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] Re: Herd likely up for grabs: kernel-misc

2016-01-20 Thread Rich Freeman 
On Wed, Jan 20, 2016 at 2:48 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Mike Frysinger posted on Wed, 20 Jan 2016 13:40:04 -0500 as excerpted:
>
>> if base-system@ isn't going to maintain it, we'll punt it from the herd
>> -mike
>
> Umm, you mean project, right?  Because the whole discussion here is part
> of getting rid of herds.  =:^)
>

Hey, some of us are still getting used to /usr/portage being the
"Gentoo Repo."  :)

-- 
Rich

[gentoo-dev] [PATCH 13/15] cmake-utils.eclass: ban helper functions in EAPI 6 and later

2016-01-20 Thread Michael Palimaka 
https://archives.gentoo.org/gentoo-dev/message/6ff6dedb44fff4289764dc5eb960e1c6

Gentoo-bug: 514384
---
 eclass/cmake-utils.eclass | 12 
 1 file changed, 12 insertions(+)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index 960b34b..507d27d 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -161,6 +161,11 @@ unset CMAKEDEPEND
 _cmake_use_me_now() {
debug-print-function ${FUNCNAME} "$@"
 
+   local arg=$2
+   [[ ! -z $3 ]] && arg=$3
+
+   has "${EAPI:-0}" 2 3 4 5 || die "${FUNCNAME[1]} is banned in EAPI 6 and 
later: use -D$1${arg}=\"\$(usex $2)\" instead"
+
local uper capitalised x
[[ -z $2 ]] && die "cmake-utils_use-$1  []"
if [[ ! -z $3 ]]; then
@@ -178,6 +183,13 @@ _cmake_use_me_now() {
 _cmake_use_me_now_inverted() {
debug-print-function ${FUNCNAME} "$@"
 
+   local arg=$2
+   [[ ! -z $3 ]] && arg=$3
+
+   if ! has "${EAPI:-0}" 2 3 4 5 && [[ "${FUNCNAME[1]}" != 
cmake-utils_use_find_package ]] ; then
+   die "${FUNCNAME[1]} is banned in EAPI 6 and later: use 
-D$1${arg}=\"\$(usex $2)\" insteadss"
+   fi
+
local uper capitalised x
[[ -z $2 ]] && die "cmake-utils_use-$1  []"
if [[ ! -z $3 ]]; then
-- 
2.4.10

[gentoo-dev] [PATCH 00/15] EAPI 6 support for cmake-utils.eclas

2016-01-20 Thread Michael Palimaka 
To follow is a series of patches to enable EAPI 6 support in cmake-utils.eclass
and some other general cleanups.

Michael Palimaka (14):
  cmake-utils.eclass: reorder a bit
  cmake-utils.eclass: declare some variables local
  cmake-utils.eclass: use a proper if statement
  cmake-utils.eclass: remove duplicate CMAKE_REMOVE_MODULES
  cmake-utils.eclass: ban WANT_CMAKE in EAPI 6 and later
  cmake-utils.eclass: replace replace comment_add_subdirectory with a
namespaced version
  cmake-utils.eclass: namespace some private functions
  cmake-utils.eclass: move $S modifications to src_prepare in EAPI 6 and
later
  cmake-utils.eclass: ban non-array usage of mycmakeargs in EAPI 6 and
later
  cmake-utils.eclass: use default_src_prepare in EAPI 6 and later
  cmake-utils.eclass: require two arguments for
cmake-utils_use_find_package in EAPI 6 and later
  cmake-utils.eclass: ban helper functions in EAPI 6 and later
  cmake-utils.eclass: enable EAPI 6
  cmake-utils.eclass: update copyright year

Nikoli (1):
  cmake-utils.eclass: check exit codes of executed commands

 eclass/cmake-utils.eclass | 189 +-
 1 file changed, 119 insertions(+), 70 deletions(-)

-- 
2.4.10

[gentoo-dev] [PATCH 01/15] cmake-utils.eclass: reorder a bit

2016-01-20 Thread Michael Palimaka 
---
 eclass/cmake-utils.eclass | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index fd53b3a..cc4c06b 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -112,6 +112,15 @@ CMAKE_REMOVE_MODULES="${CMAKE_REMOVE_MODULES:-yes}"
 # for econf and is needed to pass TRY_RUN results when cross-compiling.
 # Should be set by user in a per-package basis in /etc/portage/package.env.
 
+case ${EAPI} in
+   2|3|4|5) : ;;
+   *) die "EAPI=${EAPI:-0} is not supported" ;;
+esac
+
+inherit toolchain-funcs multilib flag-o-matic eutils versionator
+
+EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test src_install
+
 CMAKEDEPEND=""
 case ${WANT_CMAKE} in
always)
@@ -121,14 +130,6 @@ case ${WANT_CMAKE} in
CMAKEDEPEND+="${WANT_CMAKE}? ( "
;;
 esac
-inherit toolchain-funcs multilib flag-o-matic eutils versionator
-
-case ${EAPI} in
-   2|3|4|5) : ;;
-   *) die "EAPI=${EAPI:-0} is not supported" ;;
-esac
-
-EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test src_install
 
 case ${CMAKE_MAKEFILE_GENERATOR} in
emake)
-- 
2.4.10

[gentoo-dev] [PATCH 02/15] cmake-utils.eclass: declare some variables local

2016-01-20 Thread Michael Palimaka 
Prevents them from spanning multilibs.

Gentoo-bug: 513170
---
 eclass/cmake-utils.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index cc4c06b..f361bc7 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -449,7 +449,7 @@ enable_cmake-utils_src_configure() {
_modify-cmakelists
 
# Fix xdg collision with sandbox
-   export XDG_CONFIG_HOME="${T}"
+   local -x XDG_CONFIG_HOME="${T}"
 
# @SEE CMAKE_BUILD_TYPE
if [[ ${CMAKE_BUILD_TYPE} = Gentoo ]]; then
@@ -520,7 +520,7 @@ enable_cmake-utils_src_configure() {
fi
fi
 
-   has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
+   has "${EAPI:-0}" 0 1 2 && ! use prefix && local EPREFIX=
 
if [[ ${EPREFIX} ]]; then
cat >> "${build_rules}" <<- _EOF_ || die
-- 
2.4.10

[gentoo-dev] [PATCH 09/15] cmake-utils.eclass: move $S modifications to src_prepare in EAPI 6 and later

2016-01-20 Thread Michael Palimaka 
This is the correct phase for source modifications, and additionally avoids a
multilib race condition.

Gentoo-bug: 513170
---
 eclass/cmake-utils.eclass | 44 +++-
 1 file changed, 27 insertions(+), 17 deletions(-)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index df33fd9..22c8718 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -409,11 +409,37 @@ _cmake_modify-cmakelists() {
_EOF_
 }
 
+# temporary function for moving cmake cleanups from from src_configure -> 
src_prepare.
+# bug #378850
+_cmake_cleanup_cmake() {
+   : ${CMAKE_USE_DIR:=${S}}
+
+   if [[ "${CMAKE_REMOVE_MODULES}" == "yes" ]] ; then
+   local name
+   for name in ${CMAKE_REMOVE_MODULES_LIST} ; do
+   find "${S}" -name ${name}.cmake -exec rm -v {} + || die
+   done
+   fi
+
+   # check if CMakeLists.txt exist and if no then die
+   if [[ ! -e ${CMAKE_USE_DIR}/CMakeLists.txt ]] ; then
+   eerror "Unable to locate CMakeLists.txt under:"
+   eerror "\"${CMAKE_USE_DIR}/CMakeLists.txt\""
+   eerror "Consider not inheriting the cmake eclass."
+   die "FATAL: Unable to find CMakeLists.txt"
+   fi
+
+   # Remove dangerous things.
+   _cmake_modify-cmakelists
+}
+
 enable_cmake-utils_src_prepare() {
debug-print-function ${FUNCNAME} "$@"
 
pushd "${S}" > /dev/null || die
 
+   has "${EAPI:-0}" 6 && _cmake_cleanup_cmake
+
debug-print "$FUNCNAME: PATCHES=$PATCHES"
[[ ${PATCHES[@]} ]] && epatch "${PATCHES[@]}"
 
@@ -441,26 +467,10 @@ enable_cmake-utils_src_prepare() {
 enable_cmake-utils_src_configure() {
debug-print-function ${FUNCNAME} "$@"
 
-   if [[ "${CMAKE_REMOVE_MODULES}" == "yes" ]] ; then
-   local name
-   for name in ${CMAKE_REMOVE_MODULES_LIST} ; do
-   find "${S}" -name ${name}.cmake -exec rm -v {} + || die
-   done
-   fi
+   has "${EAPI:-0}" 2 3 4 5 && _cmake_cleanup_cmake
 
_cmake_check_build_dir
 
-   # check if CMakeLists.txt exist and if no then die
-   if [[ ! -e ${CMAKE_USE_DIR}/CMakeLists.txt ]] ; then
-   eerror "Unable to locate CMakeLists.txt under:"
-   eerror "\"${CMAKE_USE_DIR}/CMakeLists.txt\""
-   eerror "Consider not inheriting the cmake eclass."
-   die "FATAL: Unable to find CMakeLists.txt"
-   fi
-
-   # Remove dangerous things.
-   _cmake_modify-cmakelists
-
# Fix xdg collision with sandbox
local -x XDG_CONFIG_HOME="${T}"
 
-- 
2.4.10

[gentoo-dev] [PATCH 08/15] cmake-utils.eclass: namespace some private functions

2016-01-20 Thread Michael Palimaka 
---
 eclass/cmake-utils.eclass | 66 +++
 1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index e8b24bd..df33fd9 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -158,7 +158,7 @@ DEPEND="${CMAKEDEPEND}"
 unset CMAKEDEPEND
 
 # Internal functions used by cmake-utils_use_*
-_use_me_now() {
+_cmake_use_me_now() {
debug-print-function ${FUNCNAME} "$@"
 
local uper capitalised x
@@ -175,7 +175,7 @@ _use_me_now() {
done
fi
 }
-_use_me_now_inverted() {
+_cmake_use_me_now_inverted() {
debug-print-function ${FUNCNAME} "$@"
 
local uper capitalised x
@@ -194,7 +194,7 @@ _use_me_now_inverted() {
 }
 
 # Determine using IN or OUT source build
-_check_build_dir() {
+_cmake_check_build_dir() {
: ${CMAKE_USE_DIR:=${S}}
if [[ -n ${CMAKE_IN_SOURCE_BUILD} ]]; then
# we build in source dir
@@ -226,7 +226,7 @@ _check_build_dir() {
 }
 
 # Determine which generator to use
-_generator_to_use() {
+_cmake_generator_to_use() {
local generator_name
 
case ${CMAKE_MAKEFILE_GENERATOR} in
@@ -283,7 +283,7 @@ comment_add_subdirectory() {
 #
 # `cmake-utils_use_with foo FOO` echoes -DWITH_FOO=ON if foo is enabled
 # and -DWITH_FOO=OFF if it is disabled.
-cmake-utils_use_with() { _use_me_now WITH_ "$@" ; }
+cmake-utils_use_with() { _cmake_use_me_now WITH_ "$@" ; }
 
 # @FUNCTION: cmake-utils_use_enable
 # @USAGE:  [flag name]
@@ -292,7 +292,7 @@ cmake-utils_use_with() { _use_me_now WITH_ "$@" ; }
 #
 # `cmake-utils_use_enable foo FOO` echoes -DENABLE_FOO=ON if foo is enabled
 # and -DENABLE_FOO=OFF if it is disabled.
-cmake-utils_use_enable() { _use_me_now ENABLE_ "$@" ; }
+cmake-utils_use_enable() { _cmake_use_me_now ENABLE_ "$@" ; }
 
 # @FUNCTION: cmake-utils_use_find_package
 # @USAGE:  [flag name]
@@ -302,7 +302,7 @@ cmake-utils_use_enable() { _use_me_now ENABLE_ "$@" ; }
 # `cmake-utils_use_find_package foo LibFoo` echoes 
-DCMAKE_DISABLE_FIND_PACKAGE_LibFoo=OFF
 # if foo is enabled and -DCMAKE_DISABLE_FIND_PACKAGE_LibFoo=ON if it is 
disabled.
 # This can be used to make find_package optional.
-cmake-utils_use_find_package() { _use_me_now_inverted 
CMAKE_DISABLE_FIND_PACKAGE_ "$@" ; }
+cmake-utils_use_find_package() { _cmake_use_me_now_inverted 
CMAKE_DISABLE_FIND_PACKAGE_ "$@" ; }
 
 # @FUNCTION: cmake-utils_use_disable
 # @USAGE:  [flag name]
@@ -311,7 +311,7 @@ cmake-utils_use_find_package() { _use_me_now_inverted 
CMAKE_DISABLE_FIND_PACKAGE
 #
 # `cmake-utils_use_enable foo FOO` echoes -DDISABLE_FOO=OFF if foo is enabled
 # and -DDISABLE_FOO=ON if it is disabled.
-cmake-utils_use_disable() { _use_me_now_inverted DISABLE_ "$@" ; }
+cmake-utils_use_disable() { _cmake_use_me_now_inverted DISABLE_ "$@" ; }
 
 # @FUNCTION: cmake-utils_use_no
 # @USAGE:  [flag name]
@@ -320,7 +320,7 @@ cmake-utils_use_disable() { _use_me_now_inverted DISABLE_ 
"$@" ; }
 #
 # `cmake-utils_use_no foo FOO` echoes -DNO_FOO=OFF if foo is enabled
 # and -DNO_FOO=ON if it is disabled.
-cmake-utils_use_no() { _use_me_now_inverted NO_ "$@" ; }
+cmake-utils_use_no() { _cmake_use_me_now_inverted NO_ "$@" ; }
 
 # @FUNCTION: cmake-utils_use_want
 # @USAGE:  [flag name]
@@ -329,7 +329,7 @@ cmake-utils_use_no() { _use_me_now_inverted NO_ "$@" ; }
 #
 # `cmake-utils_use_want foo FOO` echoes -DWANT_FOO=ON if foo is enabled
 # and -DWANT_FOO=OFF if it is disabled.
-cmake-utils_use_want() { _use_me_now WANT_ "$@" ; }
+cmake-utils_use_want() { _cmake_use_me_now WANT_ "$@" ; }
 
 # @FUNCTION: cmake-utils_use_build
 # @USAGE:  [flag name]
@@ -338,7 +338,7 @@ cmake-utils_use_want() { _use_me_now WANT_ "$@" ; }
 #
 # `cmake-utils_use_build foo FOO` echoes -DBUILD_FOO=ON if foo is enabled
 # and -DBUILD_FOO=OFF if it is disabled.
-cmake-utils_use_build() { _use_me_now BUILD_ "$@" ; }
+cmake-utils_use_build() { _cmake_use_me_now BUILD_ "$@" ; }
 
 # @FUNCTION: cmake-utils_use_has
 # @USAGE:  [flag name]
@@ -347,7 +347,7 @@ cmake-utils_use_build() { _use_me_now BUILD_ "$@" ; }
 #
 # `cmake-utils_use_has foo FOO` echoes -DHAVE_FOO=ON if foo is enabled
 # and -DHAVE_FOO=OFF if it is disabled.
-cmake-utils_use_has() { _use_me_now HAVE_ "$@" ; }
+cmake-utils_use_has() { _cmake_use_me_now HAVE_ "$@" ; }
 
 # @FUNCTION: cmake-utils_use_use
 # @USAGE:  [flag name]
@@ -356,7 +356,7 @@ cmake-utils_use_has() { _use_me_now HAVE_ "$@" ; }
 #
 # `cmake-utils_use_use foo FOO` echoes -DUSE_FOO=ON if foo is enabled
 # and -DUSE_FOO=OFF if it is disabled.
-cmake-utils_use_use() { _use_me_now USE_ "$@" ; }
+cmake-utils_use_use() { _cmake_use_me_now USE_ "$@" ; }
 
 # @FUNCTION: cmake-utils_use
 # @USAGE:  [flag name]
@@ -365,7 +365,7 @@ cmake-utils_use_use() { _use_me_now USE_ "$@" ; }
 #
 # `cmake-utils_use foo FOO` echoes -DFOO=ON if foo is enabled
 # and -DFOO=OFF if it is disabled.
-cmake-utils_use() { _use_me_now "" "$@" ; }
+cmake-utils_use() {

[gentoo-dev] [PATCH 07/15] cmake-utils.eclass: replace replace comment_add_subdirectory with a namespaced version

2016-01-20 Thread Michael Palimaka 
---
 eclass/cmake-utils.eclass | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index 1de863f..e8b24bd 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -250,11 +250,11 @@ _generator_to_use() {
echo ${generator_name}
 }
 
-# @FUNCTION: comment_add_subdirectory
+# @FUNCTION: cmake_comment_add_subdirectory
 # @USAGE: 
 # @DESCRIPTION:
 # Comment out an add_subdirectory call in CMakeLists.txt in the current 
directory
-comment_add_subdirectory() {
+cmake_comment_add_subdirectory() {
 if [[ -z ${1} ]]; then
 die "comment_add_subdirectory must be passed the directory 
name to comment"
 fi
@@ -265,6 +265,17 @@ comment_add_subdirectory() {
 fi
 }
 
+# @FUNCTION: comment_add_subdirectory
+# @USAGE: 
+# @DESCRIPTION:
+# Comment out an add_subdirectory call in CMakeLists.txt in the current 
directory
+# Banned in EAPI 6 and later - use cmake_comment_add_subdirectory instead.
+comment_add_subdirectory() {
+   has "${EAPI:-0}" 2 3 4 5 || die "comment_add_subdirectory is banned in 
EAPI 6 and later - use cmake_comment_add_subdirectory instead"
+
+   cmake_comment_add_subdirectory "$@"
+}
+
 # @FUNCTION: cmake-utils_use_with
 # @USAGE:  [flag name]
 # @DESCRIPTION:
-- 
2.4.10

[gentoo-dev] [PATCH 15/15] cmake-utils.eclass: update copyright year

2016-01-20 Thread Michael Palimaka 
---
 eclass/cmake-utils.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index 70b70e2..9e8e71e 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2015 Gentoo Foundation
+# Copyright 1999-2016 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 # $Id$
 
-- 
2.4.10

[gentoo-dev] [PATCH 14/15] cmake-utils.eclass: enable EAPI 6

2016-01-20 Thread Michael Palimaka 
---
 eclass/cmake-utils.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index 507d27d..70b70e2 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -114,7 +114,7 @@ _CMAKE_UTILS_ECLASS=1
 # Should be set by user in a per-package basis in /etc/portage/package.env.
 
 case ${EAPI} in
-   2|3|4|5) : ;;
+   2|3|4|5|6) : ;;
*) die "EAPI=${EAPI:-0} is not supported" ;;
 esac
 
-- 
2.4.10

[gentoo-dev] [PATCH 10/15] cmake-utils.eclass: ban non-array usage of mycmakeargs in EAPI 6 and later

2016-01-20 Thread Michael Palimaka 
---
 eclass/cmake-utils.eclass | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index 22c8718..e6d77ef 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -583,7 +583,11 @@ enable_cmake-utils_src_configure() {
local mycmakeargstype=$(declare -p mycmakeargs 2>&-)
if [[ "${mycmakeargstype}" != "declare -a mycmakeargs="* ]]; then
if [[ -n "${mycmakeargstype}" ]] ; then
-   eqawarn "Declaring mycmakeargs as a variable is 
deprecated. Please use an array instead."
+   if has "${EAPI:-0}" 2 3 4 5 ; then
+   eqawarn "Declaring mycmakeargs as a variable is 
deprecated. Please use an array instead."
+   else
+   die "Declaring mycmakeargs as a variable is 
banned in EAPI=${EAPI}. Please use an array instead."
+   fi
fi
local mycmakeargs_local=(${mycmakeargs})
else
-- 
2.4.10

[gentoo-dev] [PATCH 03/15] cmake-utils.eclass: check exit codes of executed commands

2016-01-20 Thread Michael Palimaka 
From: Nikoli 

Gentoo-bug: 544966
---
 eclass/cmake-utils.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index f361bc7..fb80b13 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -219,7 +219,7 @@ _check_build_dir() {
# Backwards compatibility for getting the value.
CMAKE_BUILD_DIR=${BUILD_DIR}
 
-   mkdir -p "${BUILD_DIR}"
+   mkdir -p "${BUILD_DIR}" || die
echo ">>> Working in BUILD_DIR: \"$BUILD_DIR\""
 }
 
@@ -431,7 +431,7 @@ enable_cmake-utils_src_configure() {
[[ "${CMAKE_REMOVE_MODULES}" == "yes" ]] && {
local name
for name in ${CMAKE_REMOVE_MODULES_LIST} ; do
-   find "${S}" -name ${name}.cmake -exec rm -v {} +
+   find "${S}" -name ${name}.cmake -exec rm -v {} + || die
done
}
 
-- 
2.4.10

[gentoo-dev] [PATCH 05/15] cmake-utils.eclass: remove duplicate CMAKE_REMOVE_MODULES

2016-01-20 Thread Michael Palimaka 
---
 eclass/cmake-utils.eclass | 1 -
 1 file changed, 1 deletion(-)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index b2e13a1..28caed2 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -64,7 +64,6 @@ _CMAKE_UTILS_ECLASS=1
 # @DESCRIPTION:
 # Do we want to remove anything? yes or whatever else for no
 : ${CMAKE_REMOVE_MODULES:=yes}
-CMAKE_REMOVE_MODULES="${CMAKE_REMOVE_MODULES:-yes}"
 
 # @ECLASS-VARIABLE: CMAKE_REMOVE_MODULES_LIST
 # @DESCRIPTION:
-- 
2.4.10

[gentoo-dev] [PATCH 06/15] cmake-utils.eclass: ban WANT_CMAKE in EAPI 6 and later

2016-01-20 Thread Michael Palimaka 
It is basically unused across the tree and complicates the eclass. If it were
needed, it might be better to write custom ebuild phase functions instead.
---
 eclass/cmake-utils.eclass | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index 28caed2..1de863f 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -103,6 +103,8 @@ _CMAKE_UTILS_ECLASS=1
 # This is useful when only part of application is using cmake build system.
 # Valid values are: always [default], optional (where the value is the useflag
 # used for optionality)
+#
+# This is banned in EAPI 6 and later.
 : ${WANT_CMAKE:=always}
 
 # @ECLASS-VARIABLE: CMAKE_EXTRA_CACHE_FILE
@@ -125,6 +127,7 @@ case ${WANT_CMAKE} in
always)
;;
*)
+   has "${EAPI:-0}" 2 3 4 5 || die "WANT_CMAKE is banned in EAPI 6 
and later"
IUSE+=" ${WANT_CMAKE}"
CMAKEDEPEND+="${WANT_CMAKE}? ( "
;;
-- 
2.4.10

[gentoo-dev] [PATCH 04/15] cmake-utils.eclass: use a proper if statement

2016-01-20 Thread Michael Palimaka 
---
 eclass/cmake-utils.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index fb80b13..b2e13a1 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -428,12 +428,12 @@ enable_cmake-utils_src_prepare() {
 enable_cmake-utils_src_configure() {
debug-print-function ${FUNCNAME} "$@"
 
-   [[ "${CMAKE_REMOVE_MODULES}" == "yes" ]] && {
+   if [[ "${CMAKE_REMOVE_MODULES}" == "yes" ]] ; then
local name
for name in ${CMAKE_REMOVE_MODULES_LIST} ; do
find "${S}" -name ${name}.cmake -exec rm -v {} + || die
done
-   }
+   fi
 
_check_build_dir
 
-- 
2.4.10

[gentoo-dev] [PATCH 12/15] cmake-utils.eclass: require two arguments for cmake-utils_use_find_package in EAPI 6 and later

2016-01-20 Thread Michael Palimaka 
This will allow us to remove the capitalisation variants code later.
---
 eclass/cmake-utils.eclass | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index 51da1c0..960b34b 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -295,14 +295,20 @@ cmake-utils_use_with() { _cmake_use_me_now WITH_ "$@" ; }
 cmake-utils_use_enable() { _cmake_use_me_now ENABLE_ "$@" ; }
 
 # @FUNCTION: cmake-utils_use_find_package
-# @USAGE:  [flag name]
+# @USAGE:  
 # @DESCRIPTION:
 # Based on use_enable. See ebuild(5).
 #
 # `cmake-utils_use_find_package foo LibFoo` echoes 
-DCMAKE_DISABLE_FIND_PACKAGE_LibFoo=OFF
 # if foo is enabled and -DCMAKE_DISABLE_FIND_PACKAGE_LibFoo=ON if it is 
disabled.
 # This can be used to make find_package optional.
-cmake-utils_use_find_package() { _cmake_use_me_now_inverted 
CMAKE_DISABLE_FIND_PACKAGE_ "$@" ; }
+cmake-utils_use_find_package() {
+   if ! has "${EAPI:-0}" 2 3 4 5 && [[ "$#" != 2 ]] ; then
+   die "Usage: cmake-utils_use_find_package  "
+   fi
+
+   _cmake_use_me_now_inverted CMAKE_DISABLE_FIND_PACKAGE_ "$@" ;
+}
 
 # @FUNCTION: cmake-utils_use_disable
 # @USAGE:  [flag name]
-- 
2.4.10

[gentoo-dev] [PATCH 11/15] cmake-utils.eclass: use default_src_prepare in EAPI 6 and later

2016-01-20 Thread Michael Palimaka 
---
 eclass/cmake-utils.eclass | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index e6d77ef..51da1c0 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -438,13 +438,16 @@ enable_cmake-utils_src_prepare() {
 
pushd "${S}" > /dev/null || die
 
-   has "${EAPI:-0}" 6 && _cmake_cleanup_cmake
-
-   debug-print "$FUNCNAME: PATCHES=$PATCHES"
-   [[ ${PATCHES[@]} ]] && epatch "${PATCHES[@]}"
+   if ! has "${EAPI:-0}" 2 3 4 5 ; then
+   default_src_prepare
+   _cmake_cleanup_cmake
+   else
+   debug-print "$FUNCNAME: PATCHES=$PATCHES"
+   [[ ${PATCHES[@]} ]] && epatch "${PATCHES[@]}"
 
-   debug-print "$FUNCNAME: applying user patches"
-   epatch_user
+   debug-print "$FUNCNAME: applying user patches"
+   epatch_user
+   fi
 
popd > /dev/null || die
 }
-- 
2.4.10

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

2016-01-20 Thread Daniel Campbell 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/18/2016 09:44 PM, NP-Hardass wrote:
> With all of the unclaimed herds and unclaimed packages within them,
> I started to wonder what will happen after the GLEP 67 transition 
> finally comes to fruition.  This left me with some concerns and I
> was wondering what the community thinks about them, and some
> possible solutions.
> 
> There is a large number of packages from unclaimed herds that, at
> this time, look like they will not be claimed by developers.  This
> will likely result in a huge increase in maintainer-needed packages
> (and subsequent package rot).  This isn't to say that some of
> these packages weren't previously in a "maintainer-needed" like
> state, but now, they will explicitly be there.
> 
> A possible approach to reducing this is to adopt some new
> policies.
> 
> The first of which is an "adopt-a-package" type program.  In 
> functionality, this is no different than proxy-maintenance,
> however, this codifies it into an explicit policy whereby users are
> encouraged to step and take over a package.  This obviously
> requires a greater developer presence in the proxy-maint project
> (or something similar), but, personally, I think that a stronger
> dev presence in proxy-maint would be better for Gentoo as a whole.
> 
> The second policy change would be that maintainer-needed packages
> can have updates by anyone while maintaining the standard "you fix
> it if you break it" policy.  This would extend to users as well.
> With the increased ease that users can contribute via git/github,
> they should be encouraged to contribute and have their efforts
> facilitated to ease contributions to whatever packages they desire
> (within the maintainer-needed category).
> 
> Similar to the concept of a "bugday," coupled with above, an 
> "ebuildday" where users and devs get together so users can learn
> to write ebuilds and for devs to work together to maintain packages
> that usually fall outside their normal workload could prove
> beneficial to the overall health of Gentoo packaging.
> 
> Once again, these are just some random musings inspired by recent 
> events on the dev ML, and thought it might be worth discussing. 
> I've cc'd proxy-maint as a lot of this discussion is likely to
> involve them, and would like them to put in their official opinion
> as well.
> 
> 
> 
I like the idea behind this, but as others have already indicated,
there are some potential downfalls or redundancies. I think the
biggest problem here is, to my knowledge we don't have a way to see
how popular packages are. We don't know where to direct effort in the
tree without bugs or complaints over IRC/fora/ML. To get that
information we would need either volunteers or to violate our users'
privacy, which I'm not in favor of.

So we have maintainer-needed and proxy-maint, which from what I can
tell is a good gateway to becoming a developer. We could bring more
attention to that, but not without some support from other developers
who have an eye for spotting people who would be an asset to Gentoo.

As mgorny said, it does no good for us to assign dead packages to a
group of developers that won't give them the attention they deserve. I
know I'm guilty of it.

For better or worse, that's the nature of volunteer work. Users need
to know that Gentoo's tree is only as rich as the time and effort that
can go into it. We all have limitations on our time and energy, and if
nobody's interested or capable enough to maintain packages, then it
only makes sense to let them sit until someone comes along and either
takes the package or treecleans it. Last rites exist to ensure that
anybody who might care about a package will step up. They get 30 days,
iirc. I think that's plenty of time.

Since the tree's in git now, a user or would-be developer who wants to
revive a package still has something to work with. They'll just have
to fetch it from history, update it, and submit a PR or New-ebuild bug.

I guess what I'm saying here is I like your idea. I just don't think
we have the manpower or the interest among our users to make a big
dent. We should maybe put a *little* more attention on proxy-maint, if
they're okay with that, and let the community speak for themselves. If
packages die, it's because no developer wants to or can maintain it
and nobody in the community wanted to step up. Those that care can put
them into an overlay or step up and contribute.

My apologies if I'm coming off harsh. I don't mean to; it's just the
way FOSS development works imo.
- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWn39iAAoJEAEkDpRQOeFwo48P/jjBXPO0vb7uuIsoRaTuKJ8D
Edlzg8K35quvc09RGsofP2zC+Ywt/Qrh+reHWZxhrviZqpiwIbp7rUL0CnJJdku9
6NNtTsQDpcVAOWgIhIzqoZ/Ld0AJI+SqX2XwvLpGqzSqbZLTujD8IOHhjSqPH6bp

[gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

2016-01-20 Thread Dirkjan Ochtman 
On Wed, Jan 13, 2016 at 6:13 PM, Dirkjan Ochtman  wrote:
> After what feels like ages, we're just about ready to stabilize
> apache-2.4. Since this is a major upgrade that in many cases require
> configuration changes, we wanted to do a news item. After some
> discussion with Lars (Poly-C), here's an initial attempt at a draft.

I'm currently attempting this upgrade on a stable system I run. It
mostly just works, although I run into trouble when trying to load
modules that are not part of www-server/apache (e.g. mod_wsgi). I
resolved this by reemerging all packages listed in `equery b
/usr/lib/apache2/modules/*`, but maybe there's a different way? Should
this be in an elog message, or part of the news item?

Cheers,

Dirkjan