Re: [gentoo-dev] [PATCH] virtualx.eclass: support EAPI 7

2018-07-26 Thread Ulrich Mueller
> On Thu, 26 Jul 2018, Virgil Dupras wrote:

> The only adjustment made here is setting BDEPEND instead of DEPEND
> when under EAPI 7.

There's a third DEPEND assignment which you've missed, at the end of
the optional|tests case.

Ulrich


pgpog9TsT6GuR.pgp
Description: PGP signature


Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-26 Thread Benda Xu
Thanks Ben,

Ben Kohler  writes:

> To stay on the original track, I was suggesting adding it to the linux
> profile component, not base.  And people who are unwilling to use udev
> would disable it globally, like people who are unwilling to use pam or
> ipv6.
>
> But I understand where you're coming from in general-- that we've
> already achieved a good minimal balance in enabling udev only where
> it's really needed, and enabling it in linux make.defaults will make
> it difficult to get back to that state.
>
> So I will just continue to ask for IUSE=+udev where I believe it's
> very important for sane functionality of a particular package.  In
> other words, I'm no longer pushing for the make.defaults change.

Glad we are back to the common ground again.  Have fun hacking.

Yours,
Benda



Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-26 Thread Benda Xu
Hi Rich,

Rich Freeman  writes:

> I don't believe anybody suggested making Gentoo harder to customize.
> This is just about setting reasonable defaults.
>
> You can run a server without bash, openrc, sysvinit, or glibc.  Should
> these also be removed from the base profile?

A reasonable default implies a stable default, the one that does not
change for a weak reason.

The reasons are weak for switching udev on, and weak for switching
glibc, openrc, bash etc. off.

If it ain't broke don't fix it.  Changes without consensus cause more
trouble than good.

Yours,
Benda



Re: [gentoo-dev] Packages / Project up for grabs

2018-07-26 Thread Jimi Huotari
> In addition, I left the lxqt project, which now is empty. Feel free
> to join or dissolve it.

I've added myself, as I've been using and maintaining the live ebuilds
in the Qt overlay.




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] libretro-core.eclass: An eclass to streamline the construction of Libretro core ebuilds

2018-07-26 Thread Michał Górny
W dniu czw, 26.07.2018 o godzinie 15∶12 -0400, użytkownik Craig Andrews
napisał:
> I'm proposing the addition of a new eclass,  libretro-core.eclass, which 
> I'll use when adding a number of libretro ebuilds.
> 
> The pull request which includes this eclass as well as a few ebuilds 
> using it (with more to come) can be found at 
> https://github.com/gentoo/gentoo/pull/9330
> 
> Thanks,
> ~Craig
> 
> ---
>   eclass/libretro-core.eclass | 168 
>   1 file changed, 168 insertions(+)
>   create mode 100644 eclass/libretro-core.eclass
> 
> diff --git a/eclass/libretro-core.eclass b/eclass/libretro-core.eclass
> new file mode 100644
> index ..c82420ac98cc
> --- /dev/null
> +++ b/eclass/libretro-core.eclass
> @@ -0,0 +1,168 @@
> +# Copyright 1999-2018 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# @ECLASS: libretro-core.eclass
> +# @MAINTAINER:
> +# candr...@gentoo.org
> +# @AUTHOR:
> +# Cecil Curry 
> +# Craig Andrews 
> +# @BLURB: An eclass to streamline the construction of Libretro core 
> ebuilds
> +# @DESCRIPTION:
> +# The libretro eclass is designed to streamline the construction of
> +# ebuilds for low-level Libretro core ebuilds.

That's not a very helpful description.  Description should clearly let
a layman know when he should use the eclass, and when it should not be
used.  Also some generic tips, maybe an example would be helpful.

> +
> +if [[ -z ${_LIBRETRO_CORE_ECLASS} ]]; then
> +_LIBRETRO_CORE_ECLASS=1
> +
> +IUSE="debug"
> +RDEPEND=" games-emulation/libretro-info"
> +
> +# @ECLASS-VARIABLE: LIBRETRO_CORE_NAME
> +# @REQUIRED
> +# @DESCRIPTION:
> +# Name of this Libretro core. The libretro-core_src_install() phase 
> function
> +# will install the shared library 
> "${S}/${LIBRETRO_CORE_NAME}_libretro.so" as a
> +# Libretro core. Defaults to the name of the current package excluding 
> the
> +# "libretro-" prefix (e.g., "mgba" for the package "libretro-mgba").
> +: ${LIBRETRO_CORE_NAME:=${PN#libretro-}}
> +
> +# @ECLASS-VARIABLE: LIBRETRO_COMMIT_SHA
> +# @DESCRIPTION:
> +# Commit SHA used for SRC_URI will die if not set in < ebuilds.
> +# Needs to be set before inherit.
> +
> +# @ECLASS-VARIABLE: LIBRETRO_REPO_NAME
> +# @REQUIRED
> +# @DESCRIPTION:
> +# Contains the real repo name of the core formatted as 
> "repouser/reponame".
> +# Needs to be set before inherit. Otherwise defaults to 
> "libretro/${PN}"
> +: ${LIBRETRO_REPO_NAME:="libretro/libretro-${LIBRETRO_CORE_NAME}"}
> +
> +: ${HOMEPAGE:="https://github.com/${LIBRETRO_REPO_NAME}"}
> +
> +if [[ ${PV} == * ]]; then
> + : ${EGIT_REPO_URI:="https://github.com/${LIBRETRO_REPO_NAME}.git"}
> + inherit git-r3
> +else
> + [[ -z "${LIBRETRO_COMMIT_SHA}" ]] && die "LIBRETRO_COMMIT_SHA must be 
> set before inherit."
> + S="${WORKDIR}/${LIBRETRO_REPO_NAME##*/}-${LIBRETRO_COMMIT_SHA}"
> + : 
> ${SRC_URI:="https://github.com/${LIBRETRO_REPO_NAME}/archive/${LIBRETRO_COMMIT_SHA}.tar.gz
>  
> -> ${P}.tar.gz"}
> +fi
> +inherit flag-o-matic
> +
> +# @ECLASS-VARIABLE: LIBRETRO_CORE_LIB_FILE
> +# @REQUIRED
> +# @DESCRIPTION:
> +# Absolute path of this Libretro core's shared library.
> +: ${LIBRETRO_CORE_LIB_FILE:="${S}/${LIBRETRO_CORE_NAME}_libretro.so"}
> +
> +case "${EAPI:-0}" in
> + 6)

Why no EAPI 7?

> + EXPORT_FUNCTIONS src_unpack src_prepare src_compile src_install
> + ;;
> + *)
> + die "EAPI=${EAPI} is not supported" ;;
> +esac
> +
> +# @FUNCTION: libretro-core_src_unpack
> +# @DESCRIPTION:
> +# The libretro-core src_unpack function which is exported.
> +#
> +# This function retrieves the remote Libretro core info files.
> +libretro-core_src_unpack() {
> + # If this is a live ebuild, retrieve this core's remote repository.
> + if [[ ${PV} == * ]]; then
> + git-r3_src_unpack
> + # Add used commit SHA for version information, the above could 
> also 
> work.
> + LIBRETRO_COMMIT_SHA=$(git -C 
> "${EGIT3_STORE_DIR}/${LIBRETRO_REPO_NAME//\//_}.git" rev-parse HEAD)

It's internal implementation detail.  U can't touch this.

> + # Else, unpack this core's local tarball.
> + else
> + default_src_unpack
> + fi
> +}
> +
> +# @FUNCTION: libretro-core_src_prepare
> +# @DESCRIPTION:
> +# The libretro-core src_prepare function which is exported.
> +#
> +# This function prepares the source by making custom modifications.
> +libretro-core_src_prepare() {
> + local flags_modified=0
> + ebegin "Attempting to hack Makefiles to use custom-cflags"
> + for makefile in "${S}"/?akefile* "${S}"/target-libretro/?akefile*; do

Missing local for 'makefile'.

Do you expect names other than 'makefile*' and 'Makefile*'?  Because
this '?' looks like a ticking bomb.

> + # * Convert CRLF to LF
> + # * Expand *FLAGS to prevent potential self-references
> + # * Where LDFLAGS directly define the link 

[gentoo-dev] Packages up for grabs: app-admin/dio

2018-07-26 Thread Jonas Stein
Dear all,

The following packages are up for grabs:

app-admin/dio

after retirement of the proxied maintainer.

https://packages.gentoo.org/packages/app-admin/dio

https://bugs.gentoo.org/646802
This bug got no attention by the former proxied maintainer (also
upstream dev) for a long time.

Gentoo is the only distribution with this tool
https://repology.org/metapackage/dio/versions

I suggest to last rite this package, if nobody wants to fix this package
till 2018-08-01

-- 
Best,
Jonas





































































signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH] virtualx.eclass: support EAPI 7

2018-07-26 Thread Virgil Dupras
The only adjustment made here is setting BDEPEND instead of DEPEND when
under EAPI 7.

(first time trying this, guidance/reviews appreciated, took mgorny's
git-r3 patch as a model)
---
 eclass/virtualx.eclass | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/eclass/virtualx.eclass b/eclass/virtualx.eclass
index 38e629eef4f..cd0447a518c 100644
--- a/eclass/virtualx.eclass
+++ b/eclass/virtualx.eclass
@@ -14,7 +14,7 @@ case "${EAPI:-0}" in
0|1|2|3)
die "virtualx.eclass: EAPI ${EAPI} is too old."
;;
-   4|5|6)
+   4|5|6|7)
;;
*)
die "virtualx.eclass: EAPI ${EAPI} is not supported
yet." @@ -53,7 +53,11 @@ case ${VIRTUALX_REQUIRED} in
manual)
;;
always)
-   DEPEND="${VIRTUALX_DEPEND}"
+   if [[ ${EAPI:-0} != [0123456] ]]; then
+   BDEPEND="${VIRTUALX_DEPEND}"
+   else
+   DEPEND="${VIRTUALX_DEPEND}"
+   fi
RDEPEND=""
;;
optional|tests)
@@ -77,7 +81,11 @@ case ${VIRTUALX_REQUIRED} in
IUSE="${VIRTUALX_USE}"
;;
*)
-   DEPEND="${VIRTUALX_REQUIRED}? ( ${VIRTUALX_DEPEND} )"
+   if [[ ${EAPI:-0} != [0123456] ]]; then
+   BDEPEND="${VIRTUALX_REQUIRED}? ( $
{VIRTUALX_DEPEND} )"
+   else
+   DEPEND="${VIRTUALX_REQUIRED}? ( $
{VIRTUALX_DEPEND} )"
+   fi
RDEPEND=""
IUSE="${VIRTUALX_REQUIRED}"
;;
-- 
2.16.4


pgpCWnjNj1PjS.pgp
Description: PGP signature


[gentoo-dev] Packages up for grabs: games-roguelike/mangband

2018-07-26 Thread Jonas Stein
Dear all,

The following packages are up for grabs:

games-roguelike/mangband

after retirement of the proxied maintainer.

https://packages.gentoo.org/packages/games-roguelike/mangband

Treecleaning candidate:
https://bugs.gentoo.org/661746

-- 
Best,
Jonas





































































signature.asc
Description: OpenPGP digital signature


[gentoo-dev] [PATCH] libretro-core.eclass: An eclass to streamline the construction of Libretro core ebuilds

2018-07-26 Thread Craig Andrews
I'm proposing the addition of a new eclass,  libretro-core.eclass, which 
I'll use when adding a number of libretro ebuilds.


The pull request which includes this eclass as well as a few ebuilds 
using it (with more to come) can be found at 
https://github.com/gentoo/gentoo/pull/9330


Thanks,
~Craig

---
 eclass/libretro-core.eclass | 168 
 1 file changed, 168 insertions(+)
 create mode 100644 eclass/libretro-core.eclass

diff --git a/eclass/libretro-core.eclass b/eclass/libretro-core.eclass
new file mode 100644
index ..c82420ac98cc
--- /dev/null
+++ b/eclass/libretro-core.eclass
@@ -0,0 +1,168 @@
+# Copyright 1999-2018 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: libretro-core.eclass
+# @MAINTAINER:
+# candr...@gentoo.org
+# @AUTHOR:
+# Cecil Curry 
+# Craig Andrews 
+# @BLURB: An eclass to streamline the construction of Libretro core 
ebuilds

+# @DESCRIPTION:
+# The libretro eclass is designed to streamline the construction of
+# ebuilds for low-level Libretro core ebuilds.
+
+if [[ -z ${_LIBRETRO_CORE_ECLASS} ]]; then
+_LIBRETRO_CORE_ECLASS=1
+
+IUSE="debug"
+RDEPEND=" games-emulation/libretro-info"
+
+# @ECLASS-VARIABLE: LIBRETRO_CORE_NAME
+# @REQUIRED
+# @DESCRIPTION:
+# Name of this Libretro core. The libretro-core_src_install() phase 
function
+# will install the shared library 
"${S}/${LIBRETRO_CORE_NAME}_libretro.so" as a
+# Libretro core. Defaults to the name of the current package excluding 
the

+# "libretro-" prefix (e.g., "mgba" for the package "libretro-mgba").
+: ${LIBRETRO_CORE_NAME:=${PN#libretro-}}
+
+# @ECLASS-VARIABLE: LIBRETRO_COMMIT_SHA
+# @DESCRIPTION:
+# Commit SHA used for SRC_URI will die if not set in < ebuilds.
+# Needs to be set before inherit.
+
+# @ECLASS-VARIABLE: LIBRETRO_REPO_NAME
+# @REQUIRED
+# @DESCRIPTION:
+# Contains the real repo name of the core formatted as 
"repouser/reponame".
+# Needs to be set before inherit. Otherwise defaults to 
"libretro/${PN}"

+: ${LIBRETRO_REPO_NAME:="libretro/libretro-${LIBRETRO_CORE_NAME}"}
+
+: ${HOMEPAGE:="https://github.com/${LIBRETRO_REPO_NAME}"}
+
+if [[ ${PV} == * ]]; then
+   : ${EGIT_REPO_URI:="https://github.com/${LIBRETRO_REPO_NAME}.git"}
+   inherit git-r3
+else
+	[[ -z "${LIBRETRO_COMMIT_SHA}" ]] && die "LIBRETRO_COMMIT_SHA must be 
set before inherit."

+   S="${WORKDIR}/${LIBRETRO_REPO_NAME##*/}-${LIBRETRO_COMMIT_SHA}"
+	: 
${SRC_URI:="https://github.com/${LIBRETRO_REPO_NAME}/archive/${LIBRETRO_COMMIT_SHA}.tar.gz 
-> ${P}.tar.gz"}

+fi
+inherit flag-o-matic
+
+# @ECLASS-VARIABLE: LIBRETRO_CORE_LIB_FILE
+# @REQUIRED
+# @DESCRIPTION:
+# Absolute path of this Libretro core's shared library.
+: ${LIBRETRO_CORE_LIB_FILE:="${S}/${LIBRETRO_CORE_NAME}_libretro.so"}
+
+case "${EAPI:-0}" in
+   6)
+   EXPORT_FUNCTIONS src_unpack src_prepare src_compile src_install
+   ;;
+   *)
+   die "EAPI=${EAPI} is not supported" ;;
+esac
+
+# @FUNCTION: libretro-core_src_unpack
+# @DESCRIPTION:
+# The libretro-core src_unpack function which is exported.
+#
+# This function retrieves the remote Libretro core info files.
+libretro-core_src_unpack() {
+   # If this is a live ebuild, retrieve this core's remote repository.
+   if [[ ${PV} == * ]]; then
+   git-r3_src_unpack
+		# Add used commit SHA for version information, the above could also 
work.
+		LIBRETRO_COMMIT_SHA=$(git -C 
"${EGIT3_STORE_DIR}/${LIBRETRO_REPO_NAME//\//_}.git" rev-parse HEAD)

+   # Else, unpack this core's local tarball.
+   else
+   default_src_unpack
+   fi
+}
+
+# @FUNCTION: libretro-core_src_prepare
+# @DESCRIPTION:
+# The libretro-core src_prepare function which is exported.
+#
+# This function prepares the source by making custom modifications.
+libretro-core_src_prepare() {
+   local flags_modified=0
+   ebegin "Attempting to hack Makefiles to use custom-cflags"
+   for makefile in "${S}"/?akefile* "${S}"/target-libretro/?akefile*; do
+   # * Convert CRLF to LF
+   # * Expand *FLAGS to prevent potential self-references
+   # * Where LDFLAGS directly define the link version
+   #   script append LDFLAGS and LIBS
+   # * Where SHARED is used to provide shared linking
+   #   flags ensure final link command includes LDFLAGS
+   #   and LIBS
+   # * Always use $(CFLAGS) when calling $(CC)
+   sed \
+   -e 's/\r$//g' \
+   -e "/flags.*=/s/-O[[:digit:]]/${CFLAGS}/g" \
+   -e "/CFLAGS.*=/s/-O[[:digit:]]/${CFLAGS}/g" \
+   -e "/.*,--version-script=.*/s/$/ ${LDFLAGS} ${LIBS}/g" \
+   -e "/\$(CC)/s/\(\$(SHARED)\)/\1 ${LDFLAGS} ${LIBS}/" \
+   -e 's/\(\$(CC)\)/\1 \$(CFLAGS)/g' \
+   -i "${makefile}" \
+   

Re: [gentoo-dev] [PATCH 1/4] desktop.eclass: domenu, fix dying on non-existing files

2018-07-26 Thread Mike Gilbert
On Thu, Jul 26, 2018 at 7:35 AM Michał Górny  wrote:
>
> The weird logic in domenu had an explicit separate clause
> for unsuccessful return on non-existing files.  This worked fine before
> EAPI 4 since '|| die' was mandatory.  However, since 'doins' started
> dying on its own, developers have assumed the same for 'domenu'
> and stopped checking the exit status.  As a result, missing files
> are now silently ignored.
>
> Change the logic to explicitly die when the file does not exist.
> To provide the best interoperability and avoid code duplication, just
> let 'doins' die on its own.

This patch series looks good to me.



[gentoo-dev] [PATCH] install-functions: refer to ${ED} instead of ${D}

2018-07-26 Thread Mike Gilbert
Since EAPI 3, the install functions use ${ED} instead of ${D}.
---
 function-reference/install-functions/text.xml | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/function-reference/install-functions/text.xml 
b/function-reference/install-functions/text.xml
index b6bd181..1134164 100644
--- a/function-reference/install-functions/text.xml
+++ b/function-reference/install-functions/text.xml
@@ -5,9 +5,8 @@
 
 
 
-The following functions, which are all provided by ebuild.sh and the 
standard
-library, handle various install-related tasks. ${D} is automatically 
handled
-for all of these functions.
+The following functions are provided by the package manager to handle various
+install-related tasks. ${ED} is prepended automatically to the install 
location.
 
 
 
@@ -271,7 +270,7 @@ the first is the source name, the second the name to use 
when installing.
   fowners
 
 
-  Call chown on the specified files in ${D}
+  Call chown on the specified files in ${ED}
 
   
   
@@ -279,7 +278,7 @@ the first is the source name, the second the name to use 
when installing.
   fperms
 
 
-  Call chmod on the specified files in ${D}
+  Call chmod on the specified files in ${ED}
 
   
   
-- 
2.18.0




Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-26 Thread Ben Kohler

On 07/26/2018 02:59 AM, Andrew Savchenko wrote:

Hi!

On Thu, 19 Jul 2018 16:51:17 -0500 Ben Kohler wrote:

I'd like to propose adding USE=udev to our linux profiles (in
profiles/default/linux/make.defaults probably).  This flag is already
enabled on desktop profiles but it also affects quite a few packages
used on non-desktop linux systems.

This flag provides useful functionality that most linux users will want.
   I'm a bit surprised that we still don't have it in all linux profiles,
but I think we've worked around this in the past by adding IUSE=+udev to
quite a few of those packages (33 packages, 116 ebuilds, by my count).

This missing flag came to my attention again on bug 661584 where lvm2
has IUSE=+udev but cryptsetup has only IUSE=udev, so non-desktop users
have a bit of a mismatch between the 2 and get ugly errors on cryptsetup.

Since this flag only affects linux, I think it makes more sense to set
it in linux profiles than to use IUSE defaults.

Any objections to this idea?


A user had contacted me with his input from the HPC world, I'm
redirecting his e-mail here. James is whitelisted now so he can
further participate in this discussion himself if necessary.

As an HPC user of Gentoo I agree that minimal and highly optimized
Gentoo setups are indeed very useful and must stay that way.

Begin forwarded message:

Date: Wed, 25 Jul 2018 13:31:59 -0400
From: james 
To: birc...@gentoo.org
Subject: udev's future


Hello Andrew,


Sorry, I do not have direct posting ability to gentoo-dev, so in
hopes of finding a dev-sponsor, I hope you will paraphrase this
email to you for the sake of preventing 'dev as a default' or base
setting of any sort.


My research and testing for  new HPC configurations, has systemd
and udev at the heart of codes to avoid to optimize the
heterogeneous nature of the clusters I'm building. In fact my
development work, although delayed due to transient-illness, is
more of a gentoo-centric convergence of embedded-gentoo, minimal
(server) gentoo, gentoo-hpc clusters and unikernels. As far as
performance and security are concerned  'less' is always better.
Those codes and ebuild that are desired are to added in a higher
level; hoping to continue the leverage the portage tree of
applications, only as dynamically required.


Avoidance of setting udev or in any form mandating any part of
systemd will have dire consequences and cost me months, if not
years  to find a way to 'totally undo' the ravages of udev.
Minimized kernels are also fundamental to my loosely-coupled
(gentoo) HPC development. Even tiny Rtos based embedded linux
systems are in the process of being included in a loosely-coupled
gentoo centric heterogeneous HPC cluster.  I would 'beg' against
making udev primary under any circumstance.


Gentoo has a unique and powerful position, just for it's position of
choice and minimizational features; After 15 years, I'd hate to have
to work in another distro, as gentoo has served me extraordinarily
well over the decades.


sincerely,
James Horton, PE

Best regards,
Andrew Savchenko

No one was ever talking about forcing udev usage, just default-enabling 
support on a few MORE packages than we already do.  Our standard linux 
stage3's are already udev-enabled.  But not udev-forced, anywhere.


Nothing about my proposal was going to force udev on people who don't 
want udev at all-- let's not even go down that rabbit hole of discussion.


I was only pushing for more consistency-- either your system would be 
fully udev-enabled, or not at all.


-Ben



[gentoo-dev] [PATCH 4/4] desktop.eclass: Add missing ||die when writing to files

2018-07-26 Thread Michał Górny
---
 eclass/desktop.eclass | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/eclass/desktop.eclass b/eclass/desktop.eclass
index 08899b4a4607..6fc72ab8ec03 100644
--- a/eclass/desktop.eclass
+++ b/eclass/desktop.eclass
@@ -174,7 +174,7 @@ make_desktop_entry() {
icon=${icon%.*}
fi
 
-   cat <<-EOF > "${desktop}"
+   cat <<-EOF > "${desktop}" || die
[Desktop Entry]
Name=${name}
Type=Application
@@ -190,7 +190,9 @@ make_desktop_entry() {
ewarn "make_desktop_entry: update your 5th arg to read 
Path=${fields}"
fields="Path=${fields}"
fi
-   [[ -n ${fields} ]] && printf '%b\n' "${fields}" >> "${desktop}"
+   if [[ -n ${fields} ]]; then
+   printf '%b\n' "${fields}" >> "${desktop}" || die
+   fi
 
(
# wrap the env here so that the 'insinto' call
@@ -217,7 +219,7 @@ make_session_desktop() {
local desktop=${T}/${wm:-${PN}}.desktop
shift 2
 
-   cat <<-EOF > "${desktop}"
+   cat <<-EOF > "${desktop}" || die
[Desktop Entry]
Name=${title}
Comment=This session logs you into ${title}
-- 
2.18.0




[gentoo-dev] [PATCH 3/4] desktop.eclass: domenu, remove unnecessary nested loop

2018-07-26 Thread Michał Górny
---
 eclass/desktop.eclass | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/eclass/desktop.eclass b/eclass/desktop.eclass
index 8f2c6d55c293..08899b4a4607 100644
--- a/eclass/desktop.eclass
+++ b/eclass/desktop.eclass
@@ -244,15 +244,13 @@ domenu() {
(
# wrap the env here so that the 'insinto' call
# doesn't corrupt the env of the caller
-   local i j ret=0
+   local i ret=0
insopts -m 0644
insinto /usr/share/applications
for i in "$@" ; do
if [[ -d ${i} ]] ; then
-   for j in "${i}"/*.desktop ; do
-   doins "${j}"
-   ((ret|=$?))
-   done
+   doins "${i}"/*.desktop
+   ((ret|=$?))
else
doins "${i}"
((ret|=$?))
-- 
2.18.0




[gentoo-dev] [PATCH 2/4] desktop.eclass: domenu, fix potential overflow in exit status

2018-07-26 Thread Michał Górny
While increasing exit status for each failure may seem brilliant
at first, it serves no purpose and has an overflow risk.  For example,
if domenu counted 256 failures, the exit status would be truncated to 0
(success).
---
 eclass/desktop.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/desktop.eclass b/eclass/desktop.eclass
index 1684a21d21f7..8f2c6d55c293 100644
--- a/eclass/desktop.eclass
+++ b/eclass/desktop.eclass
@@ -251,11 +251,11 @@ domenu() {
if [[ -d ${i} ]] ; then
for j in "${i}"/*.desktop ; do
doins "${j}"
-   ((ret+=$?))
+   ((ret|=$?))
done
else
doins "${i}"
-   ((ret+=$?))
+   ((ret|=$?))
fi
done
exit ${ret}
-- 
2.18.0




[gentoo-dev] [PATCH 1/4] desktop.eclass: domenu, fix dying on non-existing files

2018-07-26 Thread Michał Górny
The weird logic in domenu had an explicit separate clause
for unsuccessful return on non-existing files.  This worked fine before
EAPI 4 since '|| die' was mandatory.  However, since 'doins' started
dying on its own, developers have assumed the same for 'domenu'
and stopped checking the exit status.  As a result, missing files
are now silently ignored.

Change the logic to explicitly die when the file does not exist.
To provide the best interoperability and avoid code duplication, just
let 'doins' die on its own.
---
 eclass/desktop.eclass | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/eclass/desktop.eclass b/eclass/desktop.eclass
index 91521b85a821..1684a21d21f7 100644
--- a/eclass/desktop.eclass
+++ b/eclass/desktop.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2017 Gentoo Foundation
+# Copyright 1999-2018 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: desktop.eclass
@@ -248,16 +248,14 @@ domenu() {
insopts -m 0644
insinto /usr/share/applications
for i in "$@" ; do
-   if [[ -f ${i} ]] ; then
-   doins "${i}"
-   ((ret+=$?))
-   elif [[ -d ${i} ]] ; then
+   if [[ -d ${i} ]] ; then
for j in "${i}"/*.desktop ; do
doins "${j}"
((ret+=$?))
done
else
-   ((++ret))
+   doins "${i}"
+   ((ret+=$?))
fi
done
exit ${ret}
-- 
2.18.0




Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-26 Thread Andrew Savchenko
Hi!

On Thu, 19 Jul 2018 16:51:17 -0500 Ben Kohler wrote:
> I'd like to propose adding USE=udev to our linux profiles (in 
> profiles/default/linux/make.defaults probably).  This flag is already 
> enabled on desktop profiles but it also affects quite a few packages 
> used on non-desktop linux systems.
> 
> This flag provides useful functionality that most linux users will want. 
>   I'm a bit surprised that we still don't have it in all linux profiles, 
> but I think we've worked around this in the past by adding IUSE=+udev to 
> quite a few of those packages (33 packages, 116 ebuilds, by my count).
> 
> This missing flag came to my attention again on bug 661584 where lvm2 
> has IUSE=+udev but cryptsetup has only IUSE=udev, so non-desktop users 
> have a bit of a mismatch between the 2 and get ugly errors on cryptsetup.
> 
> Since this flag only affects linux, I think it makes more sense to set 
> it in linux profiles than to use IUSE defaults.
> 
> Any objections to this idea?

A user had contacted me with his input from the HPC world, I'm
redirecting his e-mail here. James is whitelisted now so he can
further participate in this discussion himself if necessary.

As an HPC user of Gentoo I agree that minimal and highly optimized
Gentoo setups are indeed very useful and must stay that way.

Begin forwarded message:

Date: Wed, 25 Jul 2018 13:31:59 -0400
From: james 
To: birc...@gentoo.org
Subject: udev's future


Hello Andrew,


Sorry, I do not have direct posting ability to gentoo-dev, so in
hopes of finding a dev-sponsor, I hope you will paraphrase this
email to you for the sake of preventing 'dev as a default' or base
setting of any sort.


My research and testing for  new HPC configurations, has systemd
and udev at the heart of codes to avoid to optimize the
heterogeneous nature of the clusters I'm building. In fact my
development work, although delayed due to transient-illness, is
more of a gentoo-centric convergence of embedded-gentoo, minimal
(server) gentoo, gentoo-hpc clusters and unikernels. As far as
performance and security are concerned  'less' is always better.
Those codes and ebuild that are desired are to added in a higher
level; hoping to continue the leverage the portage tree of
applications, only as dynamically required.


Avoidance of setting udev or in any form mandating any part of
systemd will have dire consequences and cost me months, if not
years  to find a way to 'totally undo' the ravages of udev.
Minimized kernels are also fundamental to my loosely-coupled
(gentoo) HPC development. Even tiny Rtos based embedded linux
systems are in the process of being included in a loosely-coupled
gentoo centric heterogeneous HPC cluster.  I would 'beg' against
making udev primary under any circumstance.


Gentoo has a unique and powerful position, just for it's position of
choice and minimizational features; After 15 years, I'd hate to have
to work in another distro, as gentoo has served me extraordinarily
well over the decades.


sincerely,
James Horton, PE

Best regards,
Andrew Savchenko


pgppp_tVASKom.pgp
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/2] cmake-utils.eclass: Make ninja default backend in EAPI >= 7

2018-07-26 Thread Michał Górny
W dniu czw, 26.07.2018 o godzinie 08∶35 +0200, użytkownik
s...@gentoo.org napisał:
> From: David Seifert 
> 
> * Using the ninja backend as a default is the only way to
>   massively improve src_compile core utilization, given that
>   it seems unlikely that CMake will ever produce non-recursive
>   Makefiles.
> 
>   For a benchmark, see:
>   http://www.kaizou.org/2016/09/build-benchmark-large-c-project/

For the record, 'core utilization' or speed in general is a poor
argument.  You shouldn't have brought it because it will bring
completely unnecessary bikeshed to this thread.  Gentoo developers will
argue about it not because it could benefit Gentoo in any way
but because someone is wrong on the Internet!

The primary reason for using Ninja is making verbose build output
readable, in particular getting a lot of pointless nested verbose echos
out of it.

> ---
>  eclass/cmake-utils.eclass | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> index e64502b3b9b..ed81426ddcc 100644
> --- a/eclass/cmake-utils.eclass
> +++ b/eclass/cmake-utils.eclass
> @@ -53,7 +53,8 @@ _CMAKE_UTILS_ECLASS=1
>  # @DESCRIPTION:
>  # Specify a makefile generator to be used by cmake.
>  # At this point only "emake" and "ninja" are supported.
> -: ${CMAKE_MAKEFILE_GENERATOR:=emake}
> +# In EAPI 7 and above, the default is set to "ninja",
> +# whereas in EAPIs below 7, it is set to "emake".
>  
>  # @ECLASS-VARIABLE: CMAKE_MIN_VERSION
>  # @DESCRIPTION:
> @@ -112,8 +113,13 @@ esac
>  inherit toolchain-funcs ninja-utils flag-o-matic multiprocessing xdg-utils
>  
>  case ${EAPI} in
> - 7) ;;
> - *) inherit eapi7-ver eutils multilib ;;
> + [56])
> + : ${CMAKE_MAKEFILE_GENERATOR:=emake}
> + inherit eapi7-ver eutils multilib
> + ;;
> + *)
> + : ${CMAKE_MAKEFILE_GENERATOR:=ninja}
> + ;;
>  esac
>  
>  EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test src_install

-- 
Best regards,
Michał Górny


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


Re: [gentoo-dev] [arm17] [PATCH] toolchain-funcs.eclass: Update tc-is-softfloat for new ARM triplets

2018-07-26 Thread Sergei Trofimovich
On Wed, 25 Jul 2018 23:19:13 +0100
James Le Cuirot  wrote:

> > Then we could start warning users about the fact of inconsistency and point
> > to migration procedure. And we could have cleaner ${CTARGET} matches against
> > what Gentoo expects.  
> 
> Not sure about this. As I've said, I don't want to force users to
> migrate. Would a warning be too annoying?

I don't know where to put the warning yet. It thought of it as a longer-term 
plan
not as today's change. Still would be nice to have helper today that would tell 
you
that CHOST tuple has unexpected configuration.

I would plug new helper's output as an 'einfo' into gcc and glibc packages :)

> > 5. you don't use ${CFLAGS} here. I feel we should use them as people do 
> > occasionally
> > override defaults.  
> 
> I considered it but can we reliably get the flags for CTARGET?

Maybe not.

On second thought let's not peek into users' CFLAGS. They are too volatile
WRT user settings from emerge run to run. Let's sanitize toolchain defaults 
here.

> > I suggest using *-gnueabihf. I don't think anything more generic is 
> > recognized by toolchains
> > as a hardfloat target.  
> 
> There is also musleabihf and uclibceabihf. Would *eabihf be better?

Good catch! Yes, -*eabihf is better. clang supports at least 
lib/Support/Triple.cpp:.StartsWith("eabihf", Triple::EABIHF)
lib/Support/Triple.cpp:.StartsWith("gnueabihf", Triple::GNUEABIHF)
lib/Support/Triple.cpp:.StartsWith("musleabihf", Triple::MuslEABIHF)

> > Also please link to description of what you think canonical hardfloat 
> > tuples are supposed to
> > be. Upstreams do not agree on the definition.  
> 
> I thought this was basically dictated by our profiles but okay.

The whole excercise is to attempt to unbreak clang/gcc/other-distros
interoperability. Is that correct? At least it's how I see need for change at 
all.

Given that there is no explicit meaning attached to CHOST string anywhere
we need a clear description what hardware/abi Gentoo tries to target.

Profiles don't say anything about the meaning of CHOST string. They just use it.

I'll clarify the question: what do given profile CHOST actually supposed to mean
in terms of toolchain parameters?

Example answers to the following parameters:
- ABI
- FPU ABI
- minimal ARM ISA instruction set (integer)
- assumed FPU ISA

I'll take armv7a-unknown-linux-gnueabihf as an example in gentoo today:
- ABI
  - gcc/clang: eabi
- FPU ABI
  - gcc/clang: VFP
- minimal ARM ISA instruction set
  - gcc/clang: armv7-a(?)
- assumed FPU ISA
  - gcc: VFPv3
  - clang: VFPv3+NEON

What do we do about the VFPv3/VFPv3+NEON mismatch?

Presence of neon at the very least causes glibc to disable
IFUNC handling: https://bugs.gentoo.org/657760 . It's not a bug
on it's own and does not cause the problems (I know of) but it's a
visible difference.

I'll try to add a toolchain page to describe today's Gentoo deviations
from gcc's upstream default.

armv6 answers to the above will be different.

[ not directly related but still a mismatch that will cause problems:
  PIC/PIE defaults between gcc/clang in gentoo differ on arm as well ]

-- 

  Sergei



[gentoo-dev] [PATCH 2/2] cmake-utils.eclass: Enable BUILD_SHARED_LIBS by default in EAPI >= 7

2018-07-26 Thread soap
From: David Seifert 

* Many upstreams build static libraries by default, as this is
  simpler for distribution. Developers can still override this
  variable if required.

  Examples:
  https://github.com/pezmaster31/bamtools/blob/master/CMakeLists.txt#L64
---
 eclass/cmake-utils.eclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index ed81426ddcc..f180c8c3d7d 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -623,6 +623,7 @@ cmake-utils_src_configure() {
if [[ ${EAPI} != [56] ]]; then
cat >> "${common_config}" <<- _EOF_ || die
SET (CMAKE_INSTALL_DOCDIR 
"${EPREFIX}/usr/share/doc/${PF}" CACHE PATH "")
+   SET (BUILD_SHARED_LIBS ON CACHE BOOLEAN "")
_EOF_
fi
 
-- 
2.18.0




[gentoo-dev] [PATCH 1/2] cmake-utils.eclass: Make ninja default backend in EAPI >= 7

2018-07-26 Thread soap
From: David Seifert 

* Using the ninja backend as a default is the only way to
  massively improve src_compile core utilization, given that
  it seems unlikely that CMake will ever produce non-recursive
  Makefiles.

  For a benchmark, see:
  http://www.kaizou.org/2016/09/build-benchmark-large-c-project/
---
 eclass/cmake-utils.eclass | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index e64502b3b9b..ed81426ddcc 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -53,7 +53,8 @@ _CMAKE_UTILS_ECLASS=1
 # @DESCRIPTION:
 # Specify a makefile generator to be used by cmake.
 # At this point only "emake" and "ninja" are supported.
-: ${CMAKE_MAKEFILE_GENERATOR:=emake}
+# In EAPI 7 and above, the default is set to "ninja",
+# whereas in EAPIs below 7, it is set to "emake".
 
 # @ECLASS-VARIABLE: CMAKE_MIN_VERSION
 # @DESCRIPTION:
@@ -112,8 +113,13 @@ esac
 inherit toolchain-funcs ninja-utils flag-o-matic multiprocessing xdg-utils
 
 case ${EAPI} in
-   7) ;;
-   *) inherit eapi7-ver eutils multilib ;;
+   [56])
+   : ${CMAKE_MAKEFILE_GENERATOR:=emake}
+   inherit eapi7-ver eutils multilib
+   ;;
+   *)
+   : ${CMAKE_MAKEFILE_GENERATOR:=ninja}
+   ;;
 esac
 
 EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test src_install
-- 
2.18.0