Re: [gentoo-dev] [PATCH] virtualx.eclass: support EAPI 7
> 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
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
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
> 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
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
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
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
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
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
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}
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
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
--- 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
--- 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
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
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
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
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
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
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
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