Re: [gentoo-dev] [PATCH 1/4] distutils-r1.eclass: Add distutils_enable_tests to ease testing

2019-11-04 Thread Michał Górny
Dnia November 5, 2019 5:35:48 AM UTC, Joonas Niilola  
napisał(a):
>
>Beautiful work, but is there a way to integrate "esetup.py test" into
>this as well?. 

Not sure, would use some research for that. The main question is what test 
runners (deps) are commonly used. I'd like to avoid people mistakenly assuming 
that correct deps have been added for it.

>
>
>-- juippis
>
>
>On 11/4/19 11:00 PM, Michał Górny wrote:
>> Add a helpful function to handle adding common stuff for the most
>common
>> test runners.
>>
>> Signed-off-by: Michał Górny 
>> ---
>>  eclass/distutils-r1.eclass | 60
>++
>>  1 file changed, 60 insertions(+)
>>
>> Example ebuild use sent in replies.
>>
>> diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
>> index d3eb8f22ead2..2edffdb2d7c5 100644
>> --- a/eclass/distutils-r1.eclass
>> +++ b/eclass/distutils-r1.eclass
>> @@ -232,6 +232,66 @@ fi
>>  # }
>>  # @CODE
>>  
>> +# @FUNCTION: distutils_enable_tests
>> +# @USAGE: 
>> +# @DESCRIPTION:
>> +# Set up IUSE, RESTRICT, BDEPEND and python_test() for running tests
>> +# with the specified test runner.  Also copies the current value
>> +# of RDEPEND to test?-BDEPEND.  The test-runner argument must be one
>of:
>> +#
>> +# - nose: nosetests (dev-python/nose)
>> +# - pytest: dev-python/pytest
>> +# - unittest: for built-in Python unittest module
>> +#
>> +# This function is meant as a helper for common use cases, and it
>only
>> +# takes care of basic setup.  You still need to list additional test
>> +# dependencies manually.  If you have uncommon use case, you should
>> +# not use it and instead enable tests manually.
>> +#
>> +# This function must be called in global scope, after RDEPEND has
>been
>> +# declared.  Take care not to overwrite the variables set by it.
>> +distutils_enable_tests() {
>> +debug-print-function ${FUNCNAME} "${@}"
>> +[[ ${#} -eq 1 ]] || die "${FUNCNAME} takes exactly one argument:
>test-runner"
>> +
>> +[[ ${EAPI} == [56] ]] && local BDEPEND
>> +
>> +IUSE+=" test"
>> +RESTRICT+=" !test? ( test )"
>> +BDEPEND+=" test? ("
>> +
>> +case ${1} in
>> +nose)
>> +BDEPEND+=" dev-python/nose[${PYTHON_USEDEP}]"
>> +python_test() {
>> +nosetests -v || die "Tests fail with ${EPYTHON}"
>> +}
>> +;;
>> +pytest)
>> +BDEPEND+=" dev-python/pytest[${PYTHON_USEDEP}]"
>> +python_test() {
>> +pytest -vv || die "Tests fail with ${EPYTHON}"
>> +}
>> +;;
>> +unittest)
>> +python_test() {
>> +"${EPYTHON}" -m unittest discover -v ||
>> +die "Tests fail with ${EPYTHON}"
>> +}
>> +;;
>> +*)
>> +die "${FUNCNAME}: unsupported argument: ${1}"
>> +esac
>> +
>> +BDEPEND+=" ${RDEPEND} )"
>> +
>> +[[ ${EAPI} == [56] ]] && DEPEND+=" ${BDEPEND}"
>> +
>> +# we need to ensure successful return in case we're called last,
>> +# otherwise Portage may wrongly assume sourcing failed
>> +return 0
>> +}
>> +
>>  # @FUNCTION: esetup.py
>>  # @USAGE: [...]
>>  # @DESCRIPTION:


--
Best regards, 
Michał Górny



Re: [gentoo-dev] [PATCH 1/4] distutils-r1.eclass: Add distutils_enable_tests to ease testing

2019-11-04 Thread Joonas Niilola

Beautiful work, but is there a way to integrate "esetup.py test" into
this as well?


-- juippis


On 11/4/19 11:00 PM, Michał Górny wrote:
> Add a helpful function to handle adding common stuff for the most common
> test runners.
>
> Signed-off-by: Michał Górny 
> ---
>  eclass/distutils-r1.eclass | 60 ++
>  1 file changed, 60 insertions(+)
>
> Example ebuild use sent in replies.
>
> diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
> index d3eb8f22ead2..2edffdb2d7c5 100644
> --- a/eclass/distutils-r1.eclass
> +++ b/eclass/distutils-r1.eclass
> @@ -232,6 +232,66 @@ fi
>  # }
>  # @CODE
>  
> +# @FUNCTION: distutils_enable_tests
> +# @USAGE: 
> +# @DESCRIPTION:
> +# Set up IUSE, RESTRICT, BDEPEND and python_test() for running tests
> +# with the specified test runner.  Also copies the current value
> +# of RDEPEND to test?-BDEPEND.  The test-runner argument must be one of:
> +#
> +# - nose: nosetests (dev-python/nose)
> +# - pytest: dev-python/pytest
> +# - unittest: for built-in Python unittest module
> +#
> +# This function is meant as a helper for common use cases, and it only
> +# takes care of basic setup.  You still need to list additional test
> +# dependencies manually.  If you have uncommon use case, you should
> +# not use it and instead enable tests manually.
> +#
> +# This function must be called in global scope, after RDEPEND has been
> +# declared.  Take care not to overwrite the variables set by it.
> +distutils_enable_tests() {
> + debug-print-function ${FUNCNAME} "${@}"
> + [[ ${#} -eq 1 ]] || die "${FUNCNAME} takes exactly one argument: 
> test-runner"
> +
> + [[ ${EAPI} == [56] ]] && local BDEPEND
> +
> + IUSE+=" test"
> + RESTRICT+=" !test? ( test )"
> + BDEPEND+=" test? ("
> +
> + case ${1} in
> + nose)
> + BDEPEND+=" dev-python/nose[${PYTHON_USEDEP}]"
> + python_test() {
> + nosetests -v || die "Tests fail with ${EPYTHON}"
> + }
> + ;;
> + pytest)
> + BDEPEND+=" dev-python/pytest[${PYTHON_USEDEP}]"
> + python_test() {
> + pytest -vv || die "Tests fail with ${EPYTHON}"
> + }
> + ;;
> + unittest)
> + python_test() {
> + "${EPYTHON}" -m unittest discover -v ||
> + die "Tests fail with ${EPYTHON}"
> + }
> + ;;
> + *)
> + die "${FUNCNAME}: unsupported argument: ${1}"
> + esac
> +
> + BDEPEND+=" ${RDEPEND} )"
> +
> + [[ ${EAPI} == [56] ]] && DEPEND+=" ${BDEPEND}"
> +
> + # we need to ensure successful return in case we're called last,
> + # otherwise Portage may wrongly assume sourcing failed
> + return 0
> +}
> +
>  # @FUNCTION: esetup.py
>  # @USAGE: [...]
>  # @DESCRIPTION:



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Do (old-ish) Portage QA checks comprise policy?

2019-11-04 Thread Andreas K. Huettel
> > TL;DR: If a QA check is enforced by Portage for a reasonably long time,
> > does it constitute policy?  Or can it be changed unilaterally by Portage
> > team?

> To avoid these sorts of questions in the future, 
[snip since offtopic]

> In this case, whether or not this is "policy" is beside the point. No
> one else wants to remove this check ...

If that really were the case, we wouldnt have this discussion.

And as we all know *any* action by QA will immediately lead to complaints 
about abuse of QA powers...

FTR, yes I consider that these old QA checks embody QA policy. 14 years of it.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

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


Re: [gentoo-dev] Do (old-ish) Portage QA checks comprise policy?

2019-11-04 Thread Michael Orlitzky

2. Those other files don't get installed to the root filesystem on the
 systems that we're talking about.


I do not understand what you think I'm referring to and which files you
are talking about.

The way I'm thinking of a root fs is, /bin, maybe /boot, /etc, /lib* and /sbin.



Most junk gets installed to /usr, which is mounted on a separate 
partition on the systems we're talking about.


What useless files do we install to /bin, /boot, or /sbin?

In /lib and /etc, some SMALL files that aren't used on every system do 
get installed unconditionally. This is an explicit trade-off: the files 
are SMALL by definition, and installing them unconditionally means that 
we don't have to add a bunch of USE flags, slow down portage, and bog 
down users with choices they don't care about. It also means that users 
can e.g. switch between init systems or install logrotate without having 
to rebuild @world from scratch. Since the files are SMALL, this 
trade-off is in everyone's favor.


Your static libraries aren't small, and they aren't ever going to be 
useful to anyone. There is no trade-off here.




3. Those other files generally aren't completely useless.


A number of them are in the default installation.



What files in the default installation are completely useless to 
everyone? Small files that are useless to EVERYONE are not covered by 
our existing policy, so please feel free to drop them in src_install.




Re: [gentoo-dev] Do (old-ish) Portage QA checks comprise policy?

2019-11-04 Thread William Hubbs
On Mon, Nov 04, 2019 at 06:17:55PM -0500, Michael Orlitzky wrote:
> On 11/4/19 2:40 PM, William Hubbs wrote:
> > 
> > This is a whole other thread I've been talking about for years, but if
> > we want to be concerned about dumping "garbage" on people's limited root
> > file systems, there are other things we need to re-consider, like our
> > notion that we have to install small files everywhere even though they
> > aren't always used.
> > 
> > So, if you want to talk about that, please start a whole new thread.
> > 
> 
> 1. The idea that we should fix all existing problems before we can
> prevent people from creating new ones is ridiculous.

I never said that we should fix all existing problems before we can
prevent people from creating new ones. I just said that along these
lines this is something else I thought we should talk about. It feels
like an inconsistency to me.

> 2. Those other files don't get installed to the root filesystem on the
> systems that we're talking about.

I do not understand what you think I'm referring to and which files you
are talking about.

The way I'm thinking of a root fs is, /bin, maybe /boot, /etc, /lib* and /sbin.

> 3. Those other files generally aren't completely useless.

A number of them are in the default installation.



signature.asc
Description: Digital signature


[gentoo-dev] [PATCH 3/3] kde5-functions.eclass: Drop functions/vars moved to ecm-utils

2019-11-04 Thread Andreas Sturmlechner
Functions moved to ecm-utils:
- _check_gcc_version
- punt_bogus_dep

Variable moved to ecm-utils:
- KDE_GCC_MINIMAL

Deprecated:
- _add_category_dep()
- add_frameworks_dep()
- add_plasma_dep()
- add_kdeapps_dep()
- add_qt_dep()


--- a/eclass/kde5-functions.eclass
+++ b/eclass/kde5-functions.eclass
@@ -15,23 +15,11 @@
 if [[ -z ${_KDE5_FUNCTIONS_ECLASS} ]]; then
 _KDE5_FUNCTIONS_ECLASS=1
 
-inherit toolchain-funcs
-
 case ${EAPI} in
7) ;;
*) die "EAPI=${EAPI:-0} is not supported" ;;
 esac
 
-# @ECLASS-VARIABLE: KDE_BUILD_TYPE
-# @DESCRIPTION:
-# If PV matches "**", this is automatically set to "live".
-# Otherwise, this is automatically set to "release".
-KDE_BUILD_TYPE="release"
-if [[ ${PV} = ** ]]; then
-   KDE_BUILD_TYPE="live"
-fi
-export KDE_BUILD_TYPE
-
 case ${CATEGORY} in
kde-frameworks)
[[ ${KDE_BUILD_TYPE} = live ]] && : ${FRAMEWORKS_MINIMAL:=}
@@ -65,40 +53,6 @@ esac
 # Minimum version of KDE Applications to require. This affects add_kdeapps_dep.
 : ${KDE_APPS_MINIMAL:=19.04.3}
 
-# @ECLASS-VARIABLE: KDE_GCC_MINIMAL
-# @DEFAULT_UNSET
-# @DESCRIPTION:
-# Minimum version of active GCC to require. This is checked in kde5.eclass in
-# kde5_pkg_pretend and kde5_pkg_setup.
-
-# @FUNCTION: _check_gcc_version
-# @INTERNAL
-# @DESCRIPTION:
-# Determine if the current GCC version is acceptable, otherwise die.
-_check_gcc_version() {
-   if [[ ${MERGE_TYPE} != binary && -v KDE_GCC_MINIMAL ]] && tc-is-gcc; 
then
-
-   local version=$(gcc-version)
-   local major=${version%.*}
-   local minor=${version#*.}
-   local min_major=${KDE_GCC_MINIMAL%.*}
-   local min_minor=${KDE_GCC_MINIMAL#*.}
-
-   debug-print "GCC version check activated"
-   debug-print "Version detected:"
-   debug-print "   - Full: ${version}"
-   debug-print "   - Major: ${major}"
-   debug-print "   - Minor: ${minor}"
-   debug-print "Version required:"
-   debug-print "   - Major: ${min_major}"
-   debug-print "   - Minor: ${min_minor}"
-
-   [[ ${major} -lt ${min_major} ]] || \
-   ( [[ ${major} -eq ${min_major} && ${minor} -lt 
${min_minor} ]] ) \
-   && die "Sorry, but gcc-${KDE_GCC_MINIMAL} or later is 
required for this package (found ${version})."
-   fi
-}
-
 # @FUNCTION: _add_category_dep
 # @INTERNAL
 # @DESCRIPTION:
@@ -143,6 +97,7 @@ _add_category_dep() {
 # The output of this should be added directly to DEPEND/RDEPEND, and may be
 # wrapped in a USE conditional (but not an || conditional without an extra set
 # of parentheses).
+# PORTING: no replacement
 add_frameworks_dep() {
debug-print-function ${FUNCNAME} "$@"
 
@@ -175,6 +130,7 @@ add_frameworks_dep() {
 # The output of this should be added directly to DEPEND/RDEPEND, and may be
 # wrapped in a USE conditional (but not an || conditional without an extra set
 # of parentheses).
+# PORTING: no replacement
 add_plasma_dep() {
debug-print-function ${FUNCNAME} "$@"
 
@@ -207,6 +163,7 @@ add_plasma_dep() {
 # The output of this should be added directly to DEPEND/RDEPEND, and may be
 # wrapped in a USE conditional (but not an || conditional without an extra set
 # of parentheses).
+# PORTING: no replacement
 add_kdeapps_dep() {
debug-print-function ${FUNCNAME} "$@"
 
@@ -239,6 +196,7 @@ add_kdeapps_dep() {
 # The output of this should be added directly to DEPEND/RDEPEND, and may be
 # wrapped in a USE conditional (but not an || conditional without an extra set
 # of parentheses).
+# PORTING: no replacement
 add_qt_dep() {
debug-print-function ${FUNCNAME} "$@"
 
@@ -263,6 +221,7 @@ add_qt_dep() {
 # @USAGE:  
 # @DESCRIPTION:
 # Removes a specified dependency from a find_package call with multiple 
components.
+# PORTING: Use ecm_punt_bogus_dep from ecm-utils.eclass instead.
 punt_bogus_dep() {
local prefix=${1}
local dep=${2}






[gentoo-dev] [PATCH 2/3] kde5.eclass: Inherit ecm-utils.eclass and drop moved functions/vars

2019-11-04 Thread Andreas Sturmlechner
Functions moved to ecm-utils:
- All phase functions so far exported by kde5

Variables moved to ecm-utils:
- ECM_KDEINSTALLDIRS
- KDE_DEBUG (-> ECM_DEBUG)
- KDE_DESIGNERPLUGIN (-> split into ECM_DESIGNERPLUGIN, KDE_DESIGNERPLUGIN)
- KDE_EXAMPLES (-> ECM_EXAMPLES)
- KDE_HANDBOOK (-> ECM_HANDBOOK)
- KDE_DOC_DIR (-> ECM_HANDBOOK_DIR)
- KDE_PO_DIRS (-> ECM_PO_DIRS)
- KDE_QTHELP (-> ECM_QTHELP)
- KDE_TEST (-> ECM_TEST)
- VIRTUALX_REQUIRED

Variables deprecated:
- KDE_AUTODEPS (re-use as a switch to inherit ecm-utils or cmake-utils)
  Add meta variable fallbacks in case of KDE_AUTODEPS=false;
  ECM_KDEINSTALLDIRS, KDE_DEBUG, KDE_TEST were found to be in use even
  with KDE_AUTODEPS disabled.

--- a/eclass/kde5.eclass
+++ b/eclass/kde5.eclass
@@ -31,27 +31,7 @@ if [[ -z ${KDE_ORG_NAME} ]]; then
KDE_ORG_NAME=${KMNAME:=$PN}
 fi
 
-# @ECLASS-VARIABLE: VIRTUALX_REQUIRED
-# @DESCRIPTION:
-# For proper description see virtualx.eclass manpage.
-# Here we redefine default value to be manual, if your package needs virtualx
-# for tests you should proceed with setting VIRTUALX_REQUIRED=test.
-: ${VIRTUALX_REQUIRED:=manual}
-
-inherit cmake-utils flag-o-matic kde.org kde5-functions virtualx xdg
-
-if [[ -v KDE_GCC_MINIMAL ]]; then
-   EXPORT_FUNCTIONS pkg_pretend
-fi
-
-EXPORT_FUNCTIONS pkg_setup src_prepare src_configure src_compile src_test 
src_install pkg_preinst pkg_postinst pkg_postrm
-
-# @ECLASS-VARIABLE: ECM_KDEINSTALLDIRS
-# @DESCRIPTION:
-# If set to "false", do nothing.
-# For any other value, assume the package is using KDEInstallDirs macro and 
switch
-# KDE_INSTALL_USE_QT_SYS_PATHS to ON.
-: ${ECM_KDEINSTALLDIRS:=true}
+inherit flag-o-matic kde.org kde5-functions xdg
 
 # @ECLASS-VARIABLE: KDE_AUTODEPS
 # @DESCRIPTION:
@@ -59,6 +39,7 @@ EXPORT_FUNCTIONS pkg_setup src_prepare src_configure 
src_compile src_test src_in
 # For any other value, add dependencies on dev-qt/qtcore:5, 
kde-frameworks/kf-env
 # and kde-frameworks/extra-cmake-modules:5. Additionally, required blockers may
 # be set depending on the value of CATEGORY.
+# PORTING: no replacement
 : ${KDE_AUTODEPS:=true}
 
 # @ECLASS-VARIABLE: KDE_DEBUG
@@ -66,6 +47,7 @@ EXPORT_FUNCTIONS pkg_setup src_prepare src_configure 
src_compile src_test src_in
 # If set to "false", add -DNDEBUG (via cmake-utils_src_configure) and 
-DQT_NO_DEBUG
 # to CPPFLAGS.
 # Otherwise, add debug to IUSE.
+# PORTING: ECM_DEBUG in ecm-utils.eclass
 : ${KDE_DEBUG:=true}
 
 # @ECLASS-VARIABLE: KDE_DESIGNERPLUGIN
@@ -73,12 +55,14 @@ EXPORT_FUNCTIONS pkg_setup src_prepare src_configure 
src_compile src_test src_in
 # If set to "false", do nothing.
 # Otherwise, add "designer" to IUSE to toggle build of designer plugins
 # and add the necessary DEPENDs.
+# PORTING: ECM_DESIGNERPLUGIN in ecm-utils.eclass
 : ${KDE_DESIGNERPLUGIN:=false}
 
 # @ECLASS-VARIABLE: KDE_EXAMPLES
 # @DESCRIPTION:
 # If set to "false", unconditionally ignore a top-level examples subdirectory.
 # Otherwise, add "examples" to IUSE to toggle adding that subdirectory.
+# PORTING: ECM_EXAMPLES in ecm-utils.eclass
 : ${KDE_EXAMPLES:=false}
 
 # @ECLASS-VARIABLE: KDE_HANDBOOK
@@ -90,16 +74,19 @@ EXPORT_FUNCTIONS pkg_setup src_prepare src_configure 
src_compile src_test src_in
 # when USE=!handbook. In case package requires KF5KDELibs4Support, see next:
 # If set to "forceoptional", remove a KF5DocTools dependency from the root
 # CMakeLists.txt in addition to the above.
+# PORTING: ECM_HANDBOOK in ecm-utils.eclass
 : ${KDE_HANDBOOK:=false}
 
 # @ECLASS-VARIABLE: KDE_DOC_DIR
 # @DESCRIPTION:
 # Specifies the location of the KDE handbook if not the default.
+# PORTING: ECM_HANDBOOK_DIR in ecm-utils.eclass
 : ${KDE_DOC_DIR:=doc}
 
 # @ECLASS-VARIABLE: KDE_PO_DIRS
 # @DESCRIPTION:
 # Specifies the possible locations of KDE l10n files if not the default.
+# PORTING: ECM_PO_DIRS in ecm-utils.eclass
 : ${KDE_PO_DIRS:="po poqm"}
 
 # @ECLASS-VARIABLE: KDE_QTHELP
@@ -107,6 +94,7 @@ EXPORT_FUNCTIONS pkg_setup src_prepare src_configure 
src_compile src_test src_in
 # If set to "false", do nothing.
 # Otherwise, add "doc" to IUSE, add the appropriate dependency, generate
 # and install Qt compressed help files with -DBUILD_QCH=ON when USE=doc.
+# PORTING: ECM_QTHELP in ecm-utils.eclass
 if [[ ${CATEGORY} = kde-frameworks ]]; then
: ${KDE_QTHELP:=true}
 fi
@@ -124,6 +112,7 @@ fi
 # autotest(s), unittest(s) and test(s) subdirs from *any* CMakeLists.txt in 
${S}
 # and below conditional on BUILD_TESTING. This is always meant as a short-term
 # fix and creates ${T}/${P}-tests-optional.patch to refine and submit upstream.
+# PORTING: ECM_TEST in ecm-utils.eclass
 if [[ ${CATEGORY} = kde-frameworks ]]; then
: ${KDE_TEST:=true}
 fi
@@ -163,75 +152,68 @@ case ${KDE_SUBSLOT} in
 esac
 
 case ${KDE_AUTODEPS} in
-   false)  ;;
+   false)
+   inherit cmake-utils
+   # @ECLASS-VARIABLE: ECM_KDEINSTALLDIRS
+   # @DESCRIPTION:
+   # If set to "false", do 

[gentoo-dev] [PATCH 1/3] ecm-utils.eclass: New eclass

2019-11-04 Thread Andreas Sturmlechner
Support eclass for packages that use KDE extra-cmake-modules.

This eclass is intended to streamline the creation of ebuilds for packages
that follow KDE upstream packaging conventions. It's primarily intended for
the three upstream release groups (Frameworks, Plasma, Applications) but
is also for any package that follows similar conventions.

This eclass unconditionally inherits cmake-utils.eclass and all its public
variables and helper functions (not phase functions) may be considered as part
of this eclass's API.

When used together with kde.org.eclass this will replace kde5.eclass and
kde5-functions.eclass, most of the latter is becoming obsolete.

--- /dev/null
+++ b/eclass/ecm-utils.eclass
@@ -0,0 +1,549 @@
+# Copyright 1999-2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: ecm-utils.eclass
+# @MAINTAINER:
+# k...@gentoo.org
+# @SUPPORTED_EAPIS: 7
+# @BLURB: Support eclass for packages that use KDE extra-cmake-modules.
+# @DESCRIPTION:
+# This eclass is intended to streamline the creation of ebuilds for packages
+# that follow KDE upstream packaging conventions. It's primarily intended for
+# the three upstream release groups (Frameworks, Plasma, Applications) but
+# is also for any package that follows similar conventions.
+#
+# This eclass unconditionally inherits cmake-utils.eclass and all its public
+# variables and helper functions (not phase functions) may be considered as 
part
+# of this eclass's API.
+#
+# This eclass's phase functions are not intended to be mixed and matched, so 
if
+# any phase functions are overridden the version here should also be called.
+
+if [[ -z ${_ECM_UTILS_ECLASS} ]]; then
+_ECM_UTILS_ECLASS=1
+
+# @ECLASS-VARIABLE: VIRTUALX_REQUIRED
+# @DESCRIPTION:
+# For proper description see virtualx.eclass manpage.
+# Here we redefine default value to be manual, if your package needs virtualx
+# for tests you should proceed with setting VIRTUALX_REQUIRED=test.
+: ${VIRTUALX_REQUIRED:=manual}
+
+inherit cmake-utils flag-o-matic toolchain-funcs virtualx xdg
+
+case ${EAPI} in
+   7) ;;
+   *) die "EAPI=${EAPI:-0} is not supported" ;;
+esac
+
+if [[ -v KDE_GCC_MINIMAL ]]; then
+   EXPORT_FUNCTIONS pkg_pretend
+fi
+
+EXPORT_FUNCTIONS pkg_setup src_prepare src_configure src_test pkg_preinst 
pkg_postinst pkg_postrm
+
+# @ECLASS-VARIABLE: ECM_KDEINSTALLDIRS
+# @DESCRIPTION:
+# If set to "false", do nothing.
+# For any other value, assume the package is using KDEInstallDirs macro and 
switch
+# KDE_INSTALL_USE_QT_SYS_PATHS to ON.
+: ${ECM_KDEINSTALLDIRS:=true}
+
+# @ECLASS-VARIABLE: ECM_NONGUI
+# @DESCRIPTION:
+# If set to "false", add dependency on kde-frameworks/breeze-icons
+# or kde-frameworks/oxygen-icons and run the xdg.eclass routines for
+# pkg_preinst, pkg_postinst and pkg_postrm.
+# For any other value, do nothing.
+if [[ ${CATEGORY} = kde-frameworks ]]; then
+   : ${ECM_NONGUI:=true}
+fi
+: ${ECM_NONGUI:=false}
+
+# @ECLASS-VARIABLE: ECM_DEBUG
+# @DESCRIPTION:
+# If set to "false", add -DNDEBUG (via cmake-utils_src_configure) and
+# -DQT_NO_DEBUG to CPPFLAGS.
+# Otherwise, add debug to IUSE.
+: ${ECM_DEBUG:=true}
+
+# @ECLASS-VARIABLE: ECM_DESIGNERPLUGIN
+# @DESCRIPTION:
+# If set to "false", do nothing.
+# Otherwise, add "designer" to IUSE to toggle build of designer plugins
+# and add the necessary BDEPEND.
+: ${ECM_DESIGNERPLUGIN:=false}
+
+# @ECLASS-VARIABLE: ECM_EXAMPLES
+# @DESCRIPTION:
+# If set to "false", unconditionally ignore a top-level examples 
subdirectory.
+# Otherwise, add "examples" to IUSE to toggle adding that subdirectory.
+: ${ECM_EXAMPLES:=false}
+
+# @ECLASS-VARIABLE: ECM_HANDBOOK
+# @DESCRIPTION:
+# If set to "false", do nothing.
+# Otherwise, add "+handbook" to IUSE, add the appropriate dependency, and let
+# KF5DocTools generate and install the handbook from docbook file(s) found in
+# ECM_HANDBOOK_DIR. However if USE handbook is disabled, disable build of
+# ECM_HANDBOOK_DIR in CMakeLists.txt.
+# If set to "optional", config with -
DCMAKE_DISABLE_FIND_PACKAGE_KF5DocTools=ON
+# when USE=!handbook. In case package requires KF5KDELibs4Support, see next:
+# If set to "forceoptional", remove a KF5DocTools dependency from the root
+# CMakeLists.txt in addition to the above.
+: ${ECM_HANDBOOK:=false}
+
+# @ECLASS-VARIABLE: ECM_HANDBOOK_DIR
+# @DESCRIPTION:
+# Specifies the directory containing the docbook file(s) relative to ${S} to 
be
+# processed by KF5DocTools (kdoctools_install) if not the default.
+: ${ECM_HANDBOOK_DIR:=doc}
+
+# @ECLASS-VARIABLE: ECM_PO_DIRS
+# @DESCRIPTION:
+# Specifies the top-level directories of l10n files relative to ${S} to be
+# processed by KF5I18n (ki18n_install) if not the default. If IUSE nls exists
+# and is disabled then disable build of these directories in CMakeLists.txt.
+: ${ECM_PO_DIRS:="po poqm"}
+
+# @ECLASS-VARIABLE: ECM_QTHELP
+# @DESCRIPTION:
+# If set to "false", do nothing.
+# Otherwise, add "doc" to IUSE, add the appropriate 

Re: [gentoo-dev] Do (old-ish) Portage QA checks comprise policy?

2019-11-04 Thread Michael 'veremitz' Everitt
On 04/11/19 23:17, Michael Orlitzky wrote:
> On 11/4/19 2:40 PM, William Hubbs wrote:
>>
>> This is a whole other thread I've been talking about for years, but if
>> we want to be concerned about dumping "garbage" on people's limited root
>> file systems, there are other things we need to re-consider, like our
>> notion that we have to install small files everywhere even though they
>> aren't always used.
>>
>> So, if you want to talk about that, please start a whole new thread.
>>
>
> 1. The idea that we should fix all existing problems before we can
>    prevent people from creating new ones is ridiculous.
>
> 2. Those other files don't get installed to the root filesystem on the
>    systems that we're talking about.
>
> 3. Those other files generally aren't completely useless.
>
> 4. "small files" aren't big.
>
>
Straw man anyone? I know Guy Fawkes night is coming up here in the UK ... ;)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Do (old-ish) Portage QA checks comprise policy?

2019-11-04 Thread Michael Orlitzky

On 11/4/19 2:40 PM, William Hubbs wrote:


This is a whole other thread I've been talking about for years, but if
we want to be concerned about dumping "garbage" on people's limited root
file systems, there are other things we need to re-consider, like our
notion that we have to install small files everywhere even though they
aren't always used.

So, if you want to talk about that, please start a whole new thread.



1. The idea that we should fix all existing problems before we can
   prevent people from creating new ones is ridiculous.

2. Those other files don't get installed to the root filesystem on the
   systems that we're talking about.

3. Those other files generally aren't completely useless.

4. "small files" aren't big.




Re: [gentoo-dev] Do (old-ish) Portage QA checks comprise policy?

2019-11-04 Thread William Hubbs
Hi Kent,

On Tue, Nov 05, 2019 at 10:50:09AM +1300, Kent Fredric wrote:
> On Mon, 4 Nov 2019 10:53:44 -0500
> Michael Orlitzky  wrote:
> 
> > To avoid these sorts of questions in the future, it might be worth the 
> > time it would take to vote on each of these policies formally, document 
> > them on the wiki, and then move the related checks to ::gentoo/metadata 
> > where other package managers can benefit from them (and where they can't 
> > be unilaterally nuked). Having a comprehensive list of policies will 
> > also help developers who want to Do The Right Thing and who read up on 
> > these things proactively.
> 
> I believe the place for these is in the dev-manual[1]
> 
> If not the dev-manual, then if there is some other source of authority
> where they end up, there should be some mechanism to relay them to the
> dev-manual.
> 
> Its hard to expect people to follow a policy that is mostly codified in
> tools and cultural wisdom.

You are correct. When I was on the team, the idea was that the devmanual
was the cannonical source for all qa policies.

I'm not on the team now but I would strongly support this.

William

> 
> 1: 
> https://archives.gentoo.org/gentoo-dev/message/497c28fb2dab0a480c302ba966481f4f




signature.asc
Description: Digital signature


Re: [gentoo-dev] Do (old-ish) Portage QA checks comprise policy?

2019-11-04 Thread William Hubbs
On Mon, Nov 04, 2019 at 02:05:19PM -0600, Michael Jones wrote:
> On Mon, Nov 4, 2019 at 1:26 PM William Hubbs  wrote:
> 
> >  That way is not building static libraries at all. If we go that way as
> >  a distro the support for forcing static libraries into /usr/lib* is not
> >  needed because we would just not allow static libraries.
> >
> 
> As an end user, I would be unhappy if static libraries were no longer
> supported at all. I use them regularly for my development work.

OpenRC as an example has never supported being built statically along
with pam which is turned on in Gentoo, so it would be safe for openrc to
not build them.

Let's move the discussion of static libs to a separate thread however
and continue it there.

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] Do (old-ish) Portage QA checks comprise policy?

2019-11-04 Thread Kent Fredric
On Mon, 4 Nov 2019 10:53:44 -0500
Michael Orlitzky  wrote:

> To avoid these sorts of questions in the future, it might be worth the 
> time it would take to vote on each of these policies formally, document 
> them on the wiki, and then move the related checks to ::gentoo/metadata 
> where other package managers can benefit from them (and where they can't 
> be unilaterally nuked). Having a comprehensive list of policies will 
> also help developers who want to Do The Right Thing and who read up on 
> these things proactively.

I believe the place for these is in the dev-manual[1]

If not the dev-manual, then if there is some other source of authority
where they end up, there should be some mechanism to relay them to the
dev-manual.

Its hard to expect people to follow a policy that is mostly codified in
tools and cultural wisdom.

1: 
https://archives.gentoo.org/gentoo-dev/message/497c28fb2dab0a480c302ba966481f4f


pgp8aswgf2Rwq.pgp
Description: OpenPGP digital signature


[gentoo-dev] [PATCH 3/4] dev-python/pyee: Example use of distutils_enable_tests

2019-11-04 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 dev-python/pyee/pyee-1.0.2.ebuild | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/dev-python/pyee/pyee-1.0.2.ebuild 
b/dev-python/pyee/pyee-1.0.2.ebuild
index f25af4da8a1d..dd6ccee38a9d 100644
--- a/dev-python/pyee/pyee-1.0.2.ebuild
+++ b/dev-python/pyee/pyee-1.0.2.ebuild
@@ -14,12 +14,5 @@ SRC_URI="mirror://pypi/${PN:0:1}/${PN}/${P}.tar.gz"
 SLOT="0"
 LICENSE="MIT"
 KEYWORDS="~amd64"
-IUSE="test"
 
-RDEPEND=""
-DEPEND="${RDEPEND}
-   test? ( dev-python/nose[${PYTHON_USEDEP}] )"
-
-python_test() {
-   nosetests -v || die
-}
+distutils_enable_tests nose
-- 
2.23.0




[gentoo-dev] [PATCH 4/4] dev-python/trustme: Example use of distutils_enable_tests

2019-11-04 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 dev-python/trustme/trustme-0.5.2.ebuild | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/dev-python/trustme/trustme-0.5.2.ebuild 
b/dev-python/trustme/trustme-0.5.2.ebuild
index ee3f8b306297..eb4e41b0cf42 100644
--- a/dev-python/trustme/trustme-0.5.2.ebuild
+++ b/dev-python/trustme/trustme-0.5.2.ebuild
@@ -14,20 +14,15 @@ LICENSE="|| ( Apache-2.0 MIT )"
 SLOT="0"
 KEYWORDS="~amd64 ~arm ~arm64 ~x86"
 IUSE="test"
-RESTRICT="!test? ( test )"
 
 RDEPEND="dev-python/cryptography[${PYTHON_USEDEP}]
dev-python/idna[${PYTHON_USEDEP}]
$(python_gen_cond_dep '>=dev-python/ipaddress-1.0.16[${PYTHON_USEDEP}]' 
-2 )"
-DEPEND="${RDEPEND}
-   dev-python/setuptools[${PYTHON_USEDEP}]
+DEPEND="dev-python/setuptools[${PYTHON_USEDEP}]
test? (
-   dev-python/pytest[${PYTHON_USEDEP}]
dev-python/pyopenssl[${PYTHON_USEDEP}]
dev-python/service_identity[${PYTHON_USEDEP}]
$(python_gen_cond_dep 'dev-python/futures[${PYTHON_USEDEP}]' -2 
)
)"
 
-python_test() {
-   pytest -vv || die "Tests failed under ${EPYTHON}"
-}
+distutils_enable_tests pytest
-- 
2.23.0




[gentoo-dev] [PATCH 2/4] dev-python/cssselect: Example use of distutils_enable_tests

2019-11-04 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 dev-python/cssselect/cssselect-1.0.3.ebuild | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/dev-python/cssselect/cssselect-1.0.3.ebuild 
b/dev-python/cssselect/cssselect-1.0.3.ebuild
index 2d91e85a4ac2..d4216abcd6e7 100644
--- a/dev-python/cssselect/cssselect-1.0.3.ebuild
+++ b/dev-python/cssselect/cssselect-1.0.3.ebuild
@@ -23,7 +23,7 @@ DEPEND="
doc? ( dev-python/sphinx[${PYTHON_USEDEP}] )
test? ( dev-python/lxml[${PYTHON_USEDEP}] )"
 
-RDEPEND=""
+distutils_enable_tests unittest
 
 python_prepare_all() {
# prevent non essential d'load of files in doc build
@@ -37,10 +37,6 @@ python_compile_all() {
fi
 }
 
-python_test() {
-   "${EPYTHON}" -m unittest discover -v || die "Tests fail with ${EPYTHON}"
-}
-
 python_install_all() {
use doc && local HTML_DOCS=( docs/_build/html/. )
distutils-r1_python_install_all
-- 
2.23.0




[gentoo-dev] [PATCH 1/4] distutils-r1.eclass: Add distutils_enable_tests to ease testing

2019-11-04 Thread Michał Górny
Add a helpful function to handle adding common stuff for the most common
test runners.

Signed-off-by: Michał Górny 
---
 eclass/distutils-r1.eclass | 60 ++
 1 file changed, 60 insertions(+)

Example ebuild use sent in replies.

diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index d3eb8f22ead2..2edffdb2d7c5 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -232,6 +232,66 @@ fi
 # }
 # @CODE
 
+# @FUNCTION: distutils_enable_tests
+# @USAGE: 
+# @DESCRIPTION:
+# Set up IUSE, RESTRICT, BDEPEND and python_test() for running tests
+# with the specified test runner.  Also copies the current value
+# of RDEPEND to test?-BDEPEND.  The test-runner argument must be one of:
+#
+# - nose: nosetests (dev-python/nose)
+# - pytest: dev-python/pytest
+# - unittest: for built-in Python unittest module
+#
+# This function is meant as a helper for common use cases, and it only
+# takes care of basic setup.  You still need to list additional test
+# dependencies manually.  If you have uncommon use case, you should
+# not use it and instead enable tests manually.
+#
+# This function must be called in global scope, after RDEPEND has been
+# declared.  Take care not to overwrite the variables set by it.
+distutils_enable_tests() {
+   debug-print-function ${FUNCNAME} "${@}"
+   [[ ${#} -eq 1 ]] || die "${FUNCNAME} takes exactly one argument: 
test-runner"
+
+   [[ ${EAPI} == [56] ]] && local BDEPEND
+
+   IUSE+=" test"
+   RESTRICT+=" !test? ( test )"
+   BDEPEND+=" test? ("
+
+   case ${1} in
+   nose)
+   BDEPEND+=" dev-python/nose[${PYTHON_USEDEP}]"
+   python_test() {
+   nosetests -v || die "Tests fail with ${EPYTHON}"
+   }
+   ;;
+   pytest)
+   BDEPEND+=" dev-python/pytest[${PYTHON_USEDEP}]"
+   python_test() {
+   pytest -vv || die "Tests fail with ${EPYTHON}"
+   }
+   ;;
+   unittest)
+   python_test() {
+   "${EPYTHON}" -m unittest discover -v ||
+   die "Tests fail with ${EPYTHON}"
+   }
+   ;;
+   *)
+   die "${FUNCNAME}: unsupported argument: ${1}"
+   esac
+
+   BDEPEND+=" ${RDEPEND} )"
+
+   [[ ${EAPI} == [56] ]] && DEPEND+=" ${BDEPEND}"
+
+   # we need to ensure successful return in case we're called last,
+   # otherwise Portage may wrongly assume sourcing failed
+   return 0
+}
+
 # @FUNCTION: esetup.py
 # @USAGE: [...]
 # @DESCRIPTION:
-- 
2.23.0




[gentoo-dev] Re: [PATCH] Fix tc-cpp-is-true to work with clang

2019-11-04 Thread Sergei Trofimovich
On Mon,  4 Nov 2019 10:11:20 +
Mattias Nissler  wrote:

> Clang's preprocessor likes to output a leading newline, which makes
> the comparison always fail. GCC generates additional output with certain
> flags (e.g. -ggdb3) as well. Hence, switch the test to trigger a
> preprocessor error when the condition is not true and examine the exit
> code.
> 
> Bug: https://bugs.gentoo.org/698912
> 
> Signed-off-by: Mattias Nissler 
> ---
>  eclass/toolchain-funcs.eclass | 15 +++
>  1 file changed, 7 insertions(+), 8 deletions(-)

Looks good! I'll pull it in to ::gentoo in a few days.

Thank you!

> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> index e358d484417..1bc6cbbc108 100644
> --- a/eclass/toolchain-funcs.eclass
> +++ b/eclass/toolchain-funcs.eclass
> @@ -207,14 +207,13 @@ tc-cpp-is-true() {
>   local CONDITION=${1}
>   shift
>  
> - local RESULT=$($(tc-getTARGET_CPP) "${@}" -P - <<-EOF 2>/dev/null
> - #if ${CONDITION}
> - true
> - #endif
> - EOF
> - )
> -
> - [[ ${RESULT} == true ]]
> + $(tc-getTARGET_CPP) "${@}" -P - <<-EOF >/dev/null 2>&1
> + #if ${CONDITION}
> + true
> + #else
> + #error false
> + #endif
> + EOF
>  }
>  
>  # @FUNCTION: tc-detect-is-softfloat
> -- 
> 2.21.0
> 


-- 

  Sergei



Re: [gentoo-dev] Do (old-ish) Portage QA checks comprise policy?

2019-11-04 Thread Michael Jones
On Mon, Nov 4, 2019 at 1:26 PM William Hubbs  wrote:

>  That way is not building static libraries at all. If we go that way as
>  a distro the support for forcing static libraries into /usr/lib* is not
>  needed because we would just not allow static libraries.
>

As an end user, I would be unhappy if static libraries were no longer
supported at all. I use them regularly for my development work.


Re: [gentoo-dev] Do (old-ish) Portage QA checks comprise policy?

2019-11-04 Thread William Hubbs
Hi Michael,

On Mon, Nov 04, 2019 at 10:53:44AM -0500, Michael Orlitzky wrote:
> On 11/4/19 10:01 AM, Michał Górny wrote:
> > Hi,
> > 
> > TL;DR: If a QA check is enforced by Portage for a reasonably long time,
> > does it constitute policy?  Or can it be changed unilaterally by Portage
> > team?
> > 
> 
> To avoid these sorts of questions in the future, it might be worth the 
> time it would take to vote on each of these policies formally, document 
> them on the wiki, and then move the related checks to ::gentoo/metadata 
> where other package managers can benefit from them (and where they can't 
> be unilaterally nuked). Having a comprehensive list of policies will 
> also help developers who want to Do The Right Thing and who read up on 
> these things proactively.

I actually agree with you. I am not a fan of un-written things that we
call policies, and if this is going to be a distro policy it definitely
belongs in ::gentoo not in the package manager, but also see my other
reply.

> In this case, whether or not this is "policy" is beside the point. No 
> one else wants to remove this check because it's useful and prevents 
> developers from accidentally dumping garbage onto users' (often limited) 
> root filesystems. Some people don't like to do their jobs, though, and 
> for those developers it's a lot easier to delete the check and make 
> things worse for everybody than it would be to package software 
> correctly. Just Say No. That's what QA is for. But again, it would be 
> easier to veto these obviously-stupid things if they've been documented.

This is a whole other thread I've been talking about for years, but if
we want to be concerned about dumping "garbage" on people's limited root
file systems, there are other things we need to re-consider, like our
notion that we have to install small files everywhere even though they
aren't always used.

So, if you want to talk about that, please start a whole new thread.

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] Do (old-ish) Portage QA checks comprise policy?

2019-11-04 Thread William Hubbs
On Mon, Nov 04, 2019 at 11:07:43AM -0500, Michael Orlitzky wrote:
> On 11/4/19 11:02 AM, Michał Górny wrote:
> > 
> > I did request a QA vote to confirm it.  William demands that I close it
> 
> Take a page out of the WilliamH playbook and completely ignore him.

As I said on the other list, the ignoring was mostly due to mgorny's
rude personal attack which is pending before the proctors.
 
 Asking that the qa issue be closed was because there is another way
 around it, which was supported in a conversation I had with the qa
 lead.

 That way is not building static libraries at all. If we go that way as
 a distro the support for forcing static libraries into /usr/lib* is not
 needed because we would just not allow static libraries.

 William



signature.asc
Description: Digital signature


Re: [gentoo-portage-dev] portageq not reading profile.bashrc

2019-11-04 Thread Zac Medico
On 11/4/19 10:50 AM, Joakim Tjernlund wrote:
> On Mon, 2019-11-04 at 18:35 +, Joakim Tjernlund wrote:
>>
>> I have a profile.bashrc in my profile where I try to set INSTALL_MASK:
>>
>> cat profile.bashrc
>> INSTALL_MASK="${INSTALL_MASK} $(. $(dirname "$*")/etc_file_list)"
>> export INSTALL_MASK
>> echo "profile INSTALL_MASK: ${INSTALL_MASK}"
>>
>> PKG_INSTALL_MASK="${PKG_INSTALL_MASK} ${INSTALL_MASK}"
>> export PKG_INSTALL_MASK
>> echo "profile PKG_INSTALL_MASK: ${PKG_INSTALL_MASK}"
>>
>> Using portageq envvar INSTALL_MASK I expect to see my settings but
>> INSTALL_MASK is empty.
>>
>> Am I missing something ?
>>
>>Jocke
> 
> in profile make.defaults I have
>   CONFIG_PROTECT=""
> yet I see:
> portageq envvar CONFIG_PROTECT
> /etc
> 
> Is portageq envvar somewhat broken?
> 

Well, it's complicated because CONFIG_PROTECT is an "incremental"
variable. You can try to clear it out completely by setting
CONFIG_PROTECT="-*" in profile make.defaults, but that only works if the
CONFIG_PROTECT="/etc" setting came from earlier in the inheritance
hierarchy. You can use this command to see the inheritance order:

python -c 'import portage; print("\n".join(portage.settings.profiles))'
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] portageq not reading profile.bashrc

2019-11-04 Thread Zac Medico
On 11/4/19 10:35 AM, Joakim Tjernlund wrote:
> I have a profile.bashrc in my profile where I try to set INSTALL_MASK:
> 
> cat profile.bashrc 
> INSTALL_MASK="${INSTALL_MASK} $(. $(dirname "$*")/etc_file_list)"
> export INSTALL_MASK
> echo "profile INSTALL_MASK: ${INSTALL_MASK}"
> 
> PKG_INSTALL_MASK="${PKG_INSTALL_MASK} ${INSTALL_MASK}"
> export PKG_INSTALL_MASK
> echo "profile PKG_INSTALL_MASK: ${PKG_INSTALL_MASK}"
> 
> Using portageq envvar INSTALL_MASK I expect to see my settings but
> INSTALL_MASK is empty.
> 
> Am I missing something ?
> 
>Jocke
> 

The bashrc files are only executed during ebuild phases. The portageq
envvar command only returns settings from make.defaults and make.conf
files which are parsed by python and never executed by bash.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] portageq not reading profile.bashrc

2019-11-04 Thread Joakim Tjernlund
On Mon, 2019-11-04 at 18:35 +, Joakim Tjernlund wrote:
> 
> I have a profile.bashrc in my profile where I try to set INSTALL_MASK:
> 
> cat profile.bashrc
> INSTALL_MASK="${INSTALL_MASK} $(. $(dirname "$*")/etc_file_list)"
> export INSTALL_MASK
> echo "profile INSTALL_MASK: ${INSTALL_MASK}"
> 
> PKG_INSTALL_MASK="${PKG_INSTALL_MASK} ${INSTALL_MASK}"
> export PKG_INSTALL_MASK
> echo "profile PKG_INSTALL_MASK: ${PKG_INSTALL_MASK}"
> 
> Using portageq envvar INSTALL_MASK I expect to see my settings but
> INSTALL_MASK is empty.
> 
> Am I missing something ?
> 
>Jocke

in profile make.defaults I have
  CONFIG_PROTECT=""
yet I see:
portageq envvar CONFIG_PROTECT
/etc

Is portageq envvar somewhat broken?



Re: [gentoo-dev] Deja vu

2019-11-04 Thread Michał Górny
I had a dejà vu yesterday, while bisecting mpv.  I just knew upstream
would close my bug report immediately.

-- 
Best regards,
Michał Górny



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


Re: [gentoo-dev] Deja vu

2019-11-04 Thread Vadim A. Misbakh-Soloviov
В письме от вторник, 5 ноября 2019 г. 00:14:34 +07 пользователь Michael 
Orlitzky написал:
>   * Error: The above package list contains packages which cannot be
>   * installed at the same time on the same system.

Check the ebuild version stored in /var/db/pkg :D


[gentoo-portage-dev] portageq not reading profile.bashrc

2019-11-04 Thread Joakim Tjernlund
I have a profile.bashrc in my profile where I try to set INSTALL_MASK:

cat profile.bashrc 
INSTALL_MASK="${INSTALL_MASK} $(. $(dirname "$*")/etc_file_list)"
export INSTALL_MASK
echo "profile INSTALL_MASK: ${INSTALL_MASK}"

PKG_INSTALL_MASK="${PKG_INSTALL_MASK} ${INSTALL_MASK}"
export PKG_INSTALL_MASK
echo "profile PKG_INSTALL_MASK: ${PKG_INSTALL_MASK}"

Using portageq envvar INSTALL_MASK I expect to see my settings but
INSTALL_MASK is empty.

Am I missing something ?

   Jocke


[gentoo-dev] Deja vu

2019-11-04 Thread Michael Orlitzky

 * Error: The above package list contains packages which cannot be
 * installed at the same time on the same system.

  (dev-tex/xcolor-2.12-r1:0/0::gentoo, installed) pulled in by
>=dev-tex/xcolor-2.11 required by 
(app-text/texlive-2019:0/0::gentoo, installed)



commit 6bcaed54ee9d8f0a987d4ea907dc9a110c301d13
Author: Mikle Kolyada 
Date:   Mon Nov 4 15:18:45 2019 +0300

app-text/texlive: cleanup deps

Package-Manager: Portage-2.3.76, Repoman-2.3.16
Signed-off-by: Mikle Kolyada 

diff --git a/app-text/texlive/texlive-2019.ebuild 
b/app-text/texlive/texlive-20$

index 0fa8ecad4f1..f506a836ea8 100644
--- a/app-text/texlive/texlive-2019.ebuild
+++ b/app-text/texlive/texlive-2019.ebuild
@@ -44,7 +44,6 @@ RDEPEND="${DEPEND}
>=${TEXLIVE_CAT}/texlive-latex-${PV}
luatex? ( >=${TEXLIVE_CAT}/texlive-luatex-${PV} )
>=${TEXLIVE_CAT}/texlive-latexrecommended-${PV}
-   >=dev-tex/xcolor-2.11
>=dev-tex/latex-beamer-3.36



Re: [gentoo-dev] Do (old-ish) Portage QA checks comprise policy?

2019-11-04 Thread Michael Orlitzky

On 11/4/19 11:02 AM, Michał Górny wrote:


I did request a QA vote to confirm it.  William demands that I close it


Take a page out of the WilliamH playbook and completely ignore him.



Re: [gentoo-dev] Do (old-ish) Portage QA checks comprise policy?

2019-11-04 Thread Michał Górny
On Mon, 2019-11-04 at 10:53 -0500, Michael Orlitzky wrote:
> In this case, whether or not this is "policy" is beside the point. No 
> one else wants to remove this check because it's useful and prevents 
> developers from accidentally dumping garbage onto users' (often limited) 
> root filesystems. Some people don't like to do their jobs, though, and 
> for those developers it's a lot easier to delete the check and make 
> things worse for everybody than it would be to package software 
> correctly. Just Say No. That's what QA is for. But again, it would be 
> easier to veto these obviously-stupid things if they've been documented.

I did say no.  William claims it doesn't matter.

I did request a QA vote to confirm it.  William demands that I close it
[1].

[1] 
https://archives.gentoo.org/gentoo-portage-dev/message/f655c94bacdb01c3cafcc39a7bf1af93

-- 
Best regards,
Michał Górny



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


Re: [gentoo-dev] Do (old-ish) Portage QA checks comprise policy?

2019-11-04 Thread Michael Orlitzky

On 11/4/19 10:01 AM, Michał Górny wrote:

Hi,

TL;DR: If a QA check is enforced by Portage for a reasonably long time,
does it constitute policy?  Or can it be changed unilaterally by Portage
team?



To avoid these sorts of questions in the future, it might be worth the 
time it would take to vote on each of these policies formally, document 
them on the wiki, and then move the related checks to ::gentoo/metadata 
where other package managers can benefit from them (and where they can't 
be unilaterally nuked). Having a comprehensive list of policies will 
also help developers who want to Do The Right Thing and who read up on 
these things proactively.


In this case, whether or not this is "policy" is beside the point. No 
one else wants to remove this check because it's useful and prevents 
developers from accidentally dumping garbage onto users' (often limited) 
root filesystems. Some people don't like to do their jobs, though, and 
for those developers it's a lot easier to delete the check and make 
things worse for everybody than it would be to package software 
correctly. Just Say No. That's what QA is for. But again, it would be 
easier to veto these obviously-stupid things if they've been documented.




[gentoo-dev] Do (old-ish) Portage QA checks comprise policy?

2019-11-04 Thread Michał Górny
Hi,

TL;DR: If a QA check is enforced by Portage for a reasonably long time,
does it constitute policy?  Or can it be changed unilaterally by Portage
team?


William Hubbs has recently attempted to remove one of Portage's QA
checks [1].  Not only we disagree on the change in question, we also
disagree on whether the original behavior constitutes policy.  I'd like
to bring the latter to wider discussion, without focusing on this
particular example.

FWIU, William's argument is that the QA team has not formally approved
such a policy (did QA even exist back then?), therefore it is not a
binding policy and can be changed through internal Portage patch review.

I disagree with this assessment.  This check that has been present
in Portage since at least 2005, and has reliably enforced specific way
of writing ebuilds (influencing e.g. gen_usr_ldscript() function). 
After 14 years, I believe this certainly counts as de-facto policy
and is not something to be changed lightly.  Such change needs to be
discussed on gentoo-dev@, and preferably supported by the research
of the original rationale.

This is not the only QA check in Portage that reliably affects how we
are writing ebuilds today, yet were never formally approved or written
down in developer documentation.  I think that this is partially simply
because there were never major disagreement about them, and since
Portage has reliably enforced them there were never any real need to
take them elsewhere.  I think they should be considered equally to well-
defined policies.

Hence, my question: should the policies implied by historical Portage
checks be considered official, and be changed with due diligence?  Or
should they be merely considered implementation details, and should
Portage developers make unilateral decisions on changing or removing
them?


[1] 
https://archives.gentoo.org/gentoo-portage-dev/message/6e4cfbb0ef9c36dc6511d4f2003cc458

-- 
Best regards,
Michał Górny



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


Re: [gentoo-dev] acct-{group,user}/minetest request for ID 481

2019-11-04 Thread Joonas Niilola

On 11/4/19 4:20 PM, William Breathitt Gray wrote:
> Thanks, this document is pretty convenient. It looks like 480 is free;
> would that work for Minetest?
>
> William Breathitt Gray
>

Sure, why not. Always try to check if Fedora & Arch Linux have UID/GID
assigned for your user + group, and/or that the number you reserve for a
new one isn't used for something we're going to need free also in
Gentoo. uid-gid.txt is updated and 480 requested until your PR is
reviewed / merged. Thanks!


-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] acct-{group,user}/minetest request for ID 481

2019-11-04 Thread William Breathitt Gray
On Mon, Nov 04, 2019 at 04:04:48PM +0200, Joonas Niilola wrote:
> 
> On 11/4/19 12:55 PM, Michael 'veremitz' Everitt wrote:
> > You can also look up what's currently in use at
> > https://api.gentoo.org/uid-gid.txt FYI :]
> 
> 
> (481 was updated there after the initial mail was sent) other than that,
> its a great resource.
> 
> 
> -- juippis

Thanks, this document is pretty convenient. It looks like 480 is free;
would that work for Minetest?

William Breathitt Gray



Re: [gentoo-dev] acct-{group,user}/minetest request for ID 481

2019-11-04 Thread Joonas Niilola

On 11/4/19 12:55 PM, Michael 'veremitz' Everitt wrote:
> You can also look up what's currently in use at
> https://api.gentoo.org/uid-gid.txt FYI :]


(481 was updated there after the initial mail was sent) other than that,
its a great resource.


-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] acct-{group,user}/minetest request for ID 481

2019-11-04 Thread Michael 'veremitz' Everitt
On 04/11/19 07:57, Tomas Mozes wrote:
>
> On Mon, Nov 4, 2019 at 4:50 AM Joonas Niilola  > wrote:
>
>
> On 11/4/19 1:37 AM, William Breathitt Gray wrote:
> > Hello,
> >
> > `games-action/minetest` creates a "minetest" user and group with random
> > respective IDs, used for running the Minetest server daemon. The latest
> > version bump PR (https://github.com/gentoo/gentoo/pull/13272) follows
> > GLEP 81 by creating acct-{group,user}/minetest with 481 assigned as
> > their respective IDs.
> >
> > Is this assignment all right?
> >
> > Thank you,
> >
> > William Breathitt Gray
> >
>
> Hey,
>
>
> 481 was already requested for mongodb.
>
> 
> https://archives.gentoo.org/gentoo-dev/message/b981a29d9ade23d10663f0c0ae850044
>
>
> -- juippis
>
>
> Sorry, I haven't seen this UID/GID in the ML so I used it, haven't
> checked the PRs on github. Next time, please send a mail to the ML along
> with the PR creation.
>
> Thanks,
> Tomas 
You can also look up what's currently in use at
https://api.gentoo.org/uid-gid.txt FYI :]


signature.asc
Description: OpenPGP digital signature


Re: [gentoo-portage-dev] [PATCH] install-qa-check.d: remove check that bans libtool files and static libs from /

2019-11-04 Thread Michał Górny
On Mon, 2019-11-04 at 04:15 -0600, William Hubbs wrote:
> I also don't like your tone in your response to Zac merging the patch.
> 
> https://archives.gentoo.org/gentoo-portage-dev/message/1abfd0499e514b7d6b70b709e9e3ae18
> 
> If I say out here that since I'm a council member I'm above you and zac
> should listen to me and apply the patch is that appropriate? I imagine
> not, so I feel the same way about you bringing your qa membership into
> the discussion.
> In my opinion, all that kind of thing leads to is people becoming angry.
> 
> I'm going to ask you to close https://bugs.gentoo.org/699254. I honestly
> do not feel that this is an appropriate way to deal with this situation.
> 

Excuse me but are you serious?  So first you choose to claim that
something is not policy because you don't see it stamped.  Then you
demand that QA doesn't vote on stamping it because... why exactly? 
Because it's 'not an appropriate way', apparently.

So what's the appropriate way?

-- 
Best regards,
Michał Górny



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


Re: [gentoo-portage-dev] [PATCH] install-qa-check.d: remove check that bans libtool files and static libs from /

2019-11-04 Thread William Hubbs
On Sun, Nov 03, 2019 at 10:37:29PM +0100, Michał Górny wrote:
> That is a really poor argument.  Something that's respected for 10+
> years and reported as QA violation is a standing policy as far as I'm
> concerned.  Just because it isn't backed by a formally stamped policy
> (at least as far as we know -- maybe it was actually stamped somewhere
> in the past?) doesn't mean you it's fine for one person to change it ad-
> hoc because it stands in his way.
> 
> I should point that I'm very concerned that you're pushing this forward
> even though:
> 
> 1) I've objected to the change itself,

You have the right to object, as does anyone, but what I take very
strong issue with is your tone and your way of dealing with the
situation. An objection with another alternative would have gone a lot
better with me.

> 2) I've pointed out that it's been sent to the wrong mailing list,
> and that this explicitly prevents a number of developers from even
> knowing that this is happening,

You rudely attacked me and accused me of something I wasn't
trying to do.

https://archives.gentoo.org/gentoo-portage-dev/message/d5be93dc7767f2256041eb2cb54b8b38
 
Then floppym responded and advised again that this is the place to send
 patches for portage.

https://archives.gentoo.org/gentoo-portage-dev/message/af686e9d2d94a9b940f8f71efdf73b2b

So, that is why this point wasn't really considered.

> 3) removing it provides a way for regressions that can have major impact
> on users and that involve much effort in reverting that.
 
 Maybe the way around this is to stop building static libs for the
 ebuilds that call gen_usr_ldscript. Once that happens and
 gen_usr_ldscript isn't called in the tree any more, this patch could be
 applied.

> So if I send a revert patch afterwards, and you object, should the patch
> be accepted because only one person objected?

This is one of our problems as a distro. there isn't a way to
measure concensus.

I also don't like your tone in your response to Zac merging the patch.

https://archives.gentoo.org/gentoo-portage-dev/message/1abfd0499e514b7d6b70b709e9e3ae18

If I say out here that since I'm a council member I'm above you and zac
should listen to me and apply the patch is that appropriate? I imagine
not, so I feel the same way about you bringing your qa membership into
the discussion.
In my opinion, all that kind of thing leads to is people becoming angry.

I'm going to ask you to close https://bugs.gentoo.org/699254. I honestly
do not feel that this is an appropriate way to deal with this situation.

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] acct-{group,user}/minetest request for ID 481

2019-11-04 Thread James Le Cuirot
On 4 November 2019 07:57:58 GMT, Tomas Mozes  wrote:
>On Mon, Nov 4, 2019 at 4:50 AM Joonas Niilola 
>wrote:
>
>>
>> On 11/4/19 1:37 AM, William Breathitt Gray wrote:
>> > Hello,
>> >
>> > `games-action/minetest` creates a "minetest" user and group with
>random
>> > respective IDs, used for running the Minetest server daemon. The
>latest
>> > version bump PR (https://github.com/gentoo/gentoo/pull/13272)
>follows
>> > GLEP 81 by creating acct-{group,user}/minetest with 481 assigned as
>> > their respective IDs.
>> >
>> > Is this assignment all right?
>> >
>> > Thank you,
>> >
>> > William Breathitt Gray
>> >
>>
>> Hey,
>>
>>
>> 481 was already requested for mongodb.
>>
>>
>>
>https://archives.gentoo.org/gentoo-dev/message/b981a29d9ade23d10663f0c0ae850044
>>
>>
>> -- juippis
>>
>>
>Sorry, I haven't seen this UID/GID in the ML so I used it, haven't
>checked
>the PRs on github. Next time, please send a mail to the ML along with
>the
>PR creation.
>
>Thanks,
>Tomas

He did but he wasn't subscribed to the list at the time so the message was 
dropped. No harm done.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.