[gentoo-dev] [PATCH] rocm.eclass: add ROCM_SKIP_GLOBALS for the USE-flags exposure.
From: Benda Xu
Low level ebuilds such as dev-util/hip and
dev-libs/rocm-opencl-runtime, unconditionally supports all the AMDGPU
cards. They do not need to define amdgpu_targets_* USE-flags. But
their src_test() call check_amdgpu() to confirm an AMDGPU is
available.
Signed-off-by: Benda Xu
---
eclass/rocm.eclass | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/eclass/rocm.eclass b/eclass/rocm.eclass
index b78dfea1cc31..9804ecde97d0 100644
--- a/eclass/rocm.eclass
+++ b/eclass/rocm.eclass
@@ -125,11 +125,26 @@ _ROCM_ECLASS=1
# DEPEND="sci-libs/rocBLAS[${ROCM_USEDEP}]"
# @CODE
+# @ECLASS_VARIABLE: ROCM_SKIP_GLOBALS
+# @DESCRIPTION:
+# Controls whether _rocm_set_globals() is executed. This variable is for
+# ebuilds that call check_amdgpu() without the need to define amdgpu_targets_*
+# USE-flags, such as dev-util/hip and dev-libs/rocm-opencl-runtime.
+#
+# Example use:
+# @CODE
+# ROCM_SKIP_GLOBALS=1
+# inherit rocm
+# @CODE
+
# @FUNCTION: _rocm_set_globals
# @DESCRIPTION:
# Set global variables useful to ebuilds: IUSE, ROCM_REQUIRED_USE, and
-# ROCM_USEDEP
+# ROCM_USEDEP, unless ROCM_SKIP_GLOBALS is set.
+
_rocm_set_globals() {
+ [[ -n ${ROCM_SKIP_GLOBALS} ]] && return
+
# Two lists of AMDGPU_TARGETS of certain ROCm version. Official support
# matrix:
#
https://docs.amd.com/bundle/ROCm-Installation-Guide-v${ROCM_VERSION}/page/Prerequisite_Actions.html.
@@ -179,7 +194,6 @@ _rocm_set_globals() {
_rocm_set_globals
unset -f _rocm_set_globals
-
# @FUNCTION: get_amdgpu_flags
# @USAGE: get_amdgpu_flags
# @DESCRIPTION:
--
2.41.0
[gentoo-dev] [PATCH] rocm.eclass: dev-util/hip as an exception, not to expose USE flags.
From: Benda Xu
Signed-off-by: Benda Xu
---
eclass/rocm.eclass | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/eclass/rocm.eclass b/eclass/rocm.eclass
index b78dfea1cc31..04f321a83c8c 100644
--- a/eclass/rocm.eclass
+++ b/eclass/rocm.eclass
@@ -176,9 +176,12 @@ _rocm_set_globals() {
local optflags=${allflags[@]/%/(-)?}
ROCM_USEDEP=${optflags// /,}
}
-_rocm_set_globals
-unset -f _rocm_set_globals
+# dev-util/hip uses checkgpu but does not need the USE flags.
+if [[ ${CATEGORY}/${PN} != dev-util/hip ]]; then
+ _rocm_set_globals
+ unset -f _rocm_set_globals
+fi
# @FUNCTION: get_amdgpu_flags
# @USAGE: get_amdgpu_flags
--
2.41.0
[gentoo-dev] [PATCH] toolchain.eclass: the configure script shebang with BROOT.
From: Benda Xu
It executes on CBUILD environment.
---
eclass/toolchain.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index 488648a82ab5..33306d3d92b1 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -1655,7 +1655,7 @@ toolchain_src_compile() {
# use of bash. Newer ones will auto-detect, but this is not harmful.
# This needs to be set for compile as well, as it's used in libtool
# generation, which will break install otherwise (at least in 3.3.6):
bug #664486
- CONFIG_SHELL="${EPREFIX}/bin/bash" \
+ CONFIG_SHELL="${BROOT}/bin/bash" \
gcc_do_make ${GCC_MAKE_TARGET}
}
--
2.34.1
[gentoo-dev] [PATCH] java-utils-2.eclass: remove redundant / from CLASSPATH.
From: Benda Xu
JAVA_PKG_JARDEST always has a leading /.
Signed-off-by: Benda Xu
---
eclass/java-utils-2.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/java-utils-2.eclass b/eclass/java-utils-2.eclass
index ed4951ac97b7..0e2ed2902842 100644
--- a/eclass/java-utils-2.eclass
+++ b/eclass/java-utils-2.eclass
@@ -373,7 +373,7 @@ java-pkg_dojar() {
insinto "${JAVA_PKG_JARDEST}"
doins "${jar}"
) || die "failed to install ${jar}"
- java-pkg_append_ JAVA_PKG_CLASSPATH
"${EPREFIX}/${JAVA_PKG_JARDEST}/${jar_basename}"
+ java-pkg_append_ JAVA_PKG_CLASSPATH
"${EPREFIX}${JAVA_PKG_JARDEST}/${jar_basename}"
debug-print "installed ${jar} to
${ED}${JAVA_PKG_JARDEST}"
# make a symlink to the original jar if it's symlink
else
--
2.32.0
[gentoo-dev] [PATCH] java-vm-2.eclass: keep EPREFIX in the dosym first argument.
From: Benda Xu
first parameter of dosym() is interpreted verbatim.
Suggested-By: Zongyu Zhang
Signed-off-by: Benda Xu
---
eclass/java-vm-2.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/java-vm-2.eclass b/eclass/java-vm-2.eclass
index d71b7285996d..d51a46ce2479 100644
--- a/eclass/java-vm-2.eclass
+++ b/eclass/java-vm-2.eclass
@@ -186,7 +186,7 @@ set_java_env() {
# Make the symlink
dodir "${JAVA_VM_DIR}"
- dosym ${java_home#${EPREFIX}} ${JAVA_VM_DIR}/${VMHANDLE}
+ dosym ${java_home} ${JAVA_VM_DIR}/${VMHANDLE}
}
@@ -228,7 +228,7 @@ java-vm_install-env() {
# Make the symlink
dodir "${JAVA_VM_DIR}"
- dosym "${java_home#${EPREFIX}}" "${JAVA_VM_DIR}/${VMHANDLE}"
+ dosym "${java_home}" "${JAVA_VM_DIR}/${VMHANDLE}"
}
--
2.25.0
[gentoo-dev] [PATCH] fcaps.eclass: skip fcaps() on Prefix.
From: Benda Xu
Gentoo Prefix runs with a normal user and cannot grant extra
capabilities. Exit gracefully with a message.
Signed-off-by: Benda Xu
---
eclass/fcaps.eclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/eclass/fcaps.eclass b/eclass/fcaps.eclass
index 467f955f5e9a..fb0af8cbbde6 100644
--- a/eclass/fcaps.eclass
+++ b/eclass/fcaps.eclass
@@ -78,6 +78,11 @@ DEPEND="filecaps? ( sys-libs/libcap )"
fcaps() {
debug-print-function ${FUNCNAME} "$@"
+ if [[ ${EUID} != 0 ]] ; then
+ einfo "Insufficient privileges to execute ${FUNCNAME},
skipping."
+ return 0
+ fi
+
# Process the user options first.
local owner='root'
local group='0'
--
2.25.0
[gentoo-dev] [PATCH] fcaps.eclass: skip fcaps() on Prefix.
From: Benda Xu
Gentoo Prefix runs with a normal user and cannot grant extra
capabilities. Exit gracefully with a message.
Signed-off-by: Benda Xu
---
eclass/fcaps.eclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/eclass/fcaps.eclass b/eclass/fcaps.eclass
index 467f955f5e9a..ddc4d3ccc6d8 100644
--- a/eclass/fcaps.eclass
+++ b/eclass/fcaps.eclass
@@ -78,6 +78,11 @@ DEPEND="filecaps? ( sys-libs/libcap )"
fcaps() {
debug-print-function ${FUNCNAME} "$@"
+ if [[ ${EUID} != 0 ]] ; then
+ einfo "Insufficient privileges to execute ${FUNCNAME}, skip."
+ return 0
+ fi
+
# Process the user options first.
local owner='root'
local group='0'
--
2.25.0
[gentoo-dev] [PATCH] fcaps.eclass: disable fcaps() on Prefix.
From: Benda Xu
Gentoo Prefix runs with a normal user and cannot grant extra
capabilities. Exit gracefully with a message.
Signed-off-by: Benda Xu
---
eclass/fcaps.eclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/eclass/fcaps.eclass b/eclass/fcaps.eclass
index 467f955f5e9a..563d177c92d5 100644
--- a/eclass/fcaps.eclass
+++ b/eclass/fcaps.eclass
@@ -78,6 +78,11 @@ DEPEND="filecaps? ( sys-libs/libcap )"
fcaps() {
debug-print-function ${FUNCNAME} "$@"
+ if [[ ${EUID} != 0 ]] ; then
+ einfo "Insufficient privileges to execute ${FUNCNAME[0]}"
+ return 0
+ fi
+
# Process the user options first.
local owner='root'
local group='0'
--
2.25.0
[gentoo-dev] [PATCH] eclass/acct-user.eclass: disable fcaps() on Prefix.
From: Benda Xu
Gentoo Prefix runs with a normal user and cannot grant extra
capabilities. Exit gracefully with a message.
Closes: https://bugs.gentoo.org/699526
Signed-off-by: Benda Xu
---
eclass/fcaps.eclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/eclass/fcaps.eclass b/eclass/fcaps.eclass
index 467f955f5e9a..563d177c92d5 100644
--- a/eclass/fcaps.eclass
+++ b/eclass/fcaps.eclass
@@ -78,6 +78,11 @@ DEPEND="filecaps? ( sys-libs/libcap )"
fcaps() {
debug-print-function ${FUNCNAME} "$@"
+ if [[ ${EUID} != 0 ]] ; then
+ einfo "Insufficient privileges to execute ${FUNCNAME[0]}"
+ return 0
+ fi
+
# Process the user options first.
local owner='root'
local group='0'
--
2.25.0
[gentoo-dev] [PATCH] ghc-package.eclass: limit the ghc parallel jobs to 64.
From: Benda Xu
If ghc spawns too many C compilers, it will exhaust file descripters.
In the reference, it was thought to be a macOS bug for aggressive fd
limits. But the ghc bug also applies to GNU/Linux, when ghc is
asked to spawn, for example 256, jobs.
This patch circumvents this ghc design flaw.
Reference: https://github.com/commercialhaskell/stack/issues/1177
Reference: https://github.com/commercialhaskell/stack/issues/1979
Signed-off-by: Benda Xu
---
eclass/ghc-package.eclass | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/eclass/ghc-package.eclass b/eclass/ghc-package.eclass
index 5361f09af1e9..d729f4a407b4 100644
--- a/eclass/ghc-package.eclass
+++ b/eclass/ghc-package.eclass
@@ -203,7 +203,9 @@ ghc-make-args() {
#https://ghc.haskell.org/trac/ghc/ticket/9221#comment:57
# SMP is a requirement for parallel GC's gen0
# 'qb' balancing.
- echo "-j$(makeopts_jobs) +RTS -A256M -qb0 -RTS"
+ local n=$(makeopts_jobs)
+ [[ ${n} -gt 64 ]] && n=64
+ echo "-j${n} +RTS -A256M -qb0 -RTS"
ghc_make_args=()
fi
echo "${ghc_make_args[@]}"
--
2.25.0
[gentoo-dev] [PATCH] eclass/acct-user.eclass: disable pkg_* on Prefix.
From: Benda Xu
Gentoo Prefix runs with a normal user and cannot manage any other user.
Exit gracefully with a message.
Closes: https://bugs.gentoo.org/709570
Signed-off-by: Benda Xu
---
eclass/acct-user.eclass | 10 ++
1 file changed, 10 insertions(+)
diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
index be6b3dd3e600..e3ec3966035d 100644
--- a/eclass/acct-user.eclass
+++ b/eclass/acct-user.eclass
@@ -360,6 +360,11 @@ acct-user_pkg_preinst() {
acct-user_pkg_postinst() {
debug-print-function ${FUNCNAME} "${@}"
+ if [[ ${EUID} != 0 ]] ; then
+ einfo "Insufficient privileges to execute ${FUNCNAME[0]}"
+ return 0
+ fi
+
# NB: eset* functions check current value
esethome "${ACCT_USER_NAME}" "${ACCT_USER_HOME}"
esetshell "${ACCT_USER_NAME}" "${ACCT_USER_SHELL}"
@@ -376,6 +381,11 @@ acct-user_pkg_postinst() {
acct-user_pkg_prerm() {
debug-print-function ${FUNCNAME} "${@}"
+ if [[ ${EUID} != 0 ]] ; then
+ einfo "Insufficient privileges to execute ${FUNCNAME[0]}"
+ return 0
+ fi
+
if [[ -z ${REPLACED_BY_VERSION} ]]; then
if [[ -z $(egetent passwd "${ACCT_USER_NAME}") ]]; then
ewarn "User account not found: ${ACCT_USER_NAME}"
--
2.25.0
[gentoo-dev] [PATCH] eclass/cmake-utils.eclass: restrict rpath hack to Prefix/rpath
From: Benda Xu
Prefix/standalone does not need it.
---
eclass/cmake-utils.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index ea1858e9735f..109b584afb39 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -612,7 +612,7 @@ cmake-utils_src_configure() {
fi
fi
- if [[ ${EPREFIX} ]]; then
+ if use prefix-guest; then
cat >> "${build_rules}" <<- _EOF_ || die
# in Prefix we need rpath and must ensure cmake gets
our default linker path
# right ... except for Darwin hosts
--
2.17.0
[gentoo-dev] [PATCH 2/2] virtual/{c,}blas: add sci-libs/blis as a candidate.
From: Benda Xu
On ld.so-based systems, runtime library switching is possible. We
use 'eselect-ldso' to flag this possibility. In this case, blis can
used as a drop-in replacement via an `eselect` call.
Otherwise If USE eselect-ldso is not set, only reference
implementation will be pulled in.
Package-Manager: Portage-2.3.52, Repoman-2.3.12
Signed-off-by: Benda Xu
---
virtual/blas/blas-3.8.ebuild | 5 -
virtual/cblas/cblas-3.8.ebuild | 5 -
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/virtual/blas/blas-3.8.ebuild b/virtual/blas/blas-3.8.ebuild
index e3807aaa8c4a..45bf1cc03013 100644
--- a/virtual/blas/blas-3.8.ebuild
+++ b/virtual/blas/blas-3.8.ebuild
@@ -9,6 +9,9 @@ KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~mips ~ppc
~ppc64 ~s390 ~sparc ~
IUSE="eselect-ldso"
RDEPEND="
- >=sci-libs/lapack-3.8.0[eselect-ldso?]
+ !eselect-ldso? ( >=sci-libs/lapack-3.8.0[-eselect-ldso] )
+ eselect-ldso? ( || (
+ >=sci-libs/lapack-3.8.0[eselect-ldso]
+ sci-libs/blis[eselect-ldso] ) )
"
DEPEND="${RDEPEND}"
diff --git a/virtual/cblas/cblas-3.8.ebuild b/virtual/cblas/cblas-3.8.ebuild
index 0b295963f8de..440e9fc4a540 100644
--- a/virtual/cblas/cblas-3.8.ebuild
+++ b/virtual/cblas/cblas-3.8.ebuild
@@ -9,6 +9,9 @@ KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~ppc ~ppc64
~s390 ~sparc ~x86 ~a
IUSE="eselect-ldso"
RDEPEND="
- >=sci-libs/lapack-3.8.0[eselect-ldso?]
+ !eselect-ldso? ( >=sci-libs/lapack-3.8.0[-eselect-ldso] )
+ eselect-ldso? ( || (
+ >=sci-libs/lapack-3.8.0[eselect-ldso]
+ sci-libs/blis[eselect-ldso] ) )
"
DEPEND="${RDEPEND}"
--
2.17.0
[gentoo-dev] [PATCH 0/2] RFC: Introducing ldso switching to BLAS/LAPACK
From: Benda Xu
The following 2 patches are to introduce the runtime switching
mechanism to BLAS/LAPACK libraries in Gentoo.
This feature is turned off by default and only the reference
BLAS/LAPACK is used to satisfy the dependencies. It can be enabled by
USE=eselect-ldso.
Sorry for the glitch to the tree caused by my mistake yesterday. I am
looking forward to your review. I am cross posting to -dev and -sci
so as to attract atention from all interested parties.
Cheers,
Benda
Benda Xu (2):
virtual/{blas,cblas,lapack,lapacke}: add virtual packages.
virtual/{c,}blas: add sci-libs/blis as a candidate.
virtual/blas/blas-3.8.ebuild | 17 +
virtual/blas/metadata.xml | 10 +++---
virtual/cblas/cblas-3.8.ebuild | 17 +
virtual/cblas/metadata.xml | 10 +++---
virtual/lapack/lapack-3.8.ebuild | 14 ++
virtual/lapack/metadata.xml| 10 +++---
virtual/lapacke/lapacke-3.8.ebuild | 14 ++
virtual/lapacke/metadata.xml | 16
8 files changed, 99 insertions(+), 9 deletions(-)
create mode 100644 virtual/blas/blas-3.8.ebuild
create mode 100644 virtual/cblas/cblas-3.8.ebuild
create mode 100644 virtual/lapack/lapack-3.8.ebuild
create mode 100644 virtual/lapacke/lapacke-3.8.ebuild
create mode 100644 virtual/lapacke/metadata.xml
--
2.17.0
[gentoo-dev] [PATCH 1/2] virtual/{blas,cblas,lapack,lapacke}: add virtual packages.
From: Benda Xu
These virtual packages are used by the BLAS/LAPACK runtime switching
mechanism.
Closes: https://github.com/gentoo/gentoo/pull/12323
Closes: https://bugs.gentoo.org/373613
Closes: https://bugs.gentoo.org/381801
Closes: https://bugs.gentoo.org/498490
Closes: https://bugs.gentoo.org/563674
Closes: https://bugs.gentoo.org/564546
Closes: https://bugs.gentoo.org/565776
Closes: https://bugs.gentoo.org/646316
Closes: https://bugs.gentoo.org/657984
Closes: https://bugs.gentoo.org/659014
Closes: https://bugs.gentoo.org/659264
Closes: https://bugs.gentoo.org/669644
Signed-off-by: Mo Zhou
Signed-off-by: Benda Xu
---
virtual/blas/blas-3.8.ebuild | 14 ++
virtual/blas/metadata.xml | 10 +++---
virtual/cblas/cblas-3.8.ebuild | 14 ++
virtual/cblas/metadata.xml | 10 +++---
virtual/lapack/lapack-3.8.ebuild | 14 ++
virtual/lapack/metadata.xml| 10 +++---
virtual/lapacke/lapacke-3.8.ebuild | 14 ++
virtual/lapacke/metadata.xml | 16
8 files changed, 93 insertions(+), 9 deletions(-)
create mode 100644 virtual/blas/blas-3.8.ebuild
create mode 100644 virtual/cblas/cblas-3.8.ebuild
create mode 100644 virtual/lapack/lapack-3.8.ebuild
create mode 100644 virtual/lapacke/lapacke-3.8.ebuild
create mode 100644 virtual/lapacke/metadata.xml
diff --git a/virtual/blas/blas-3.8.ebuild b/virtual/blas/blas-3.8.ebuild
new file mode 100644
index ..e3807aaa8c4a
--- /dev/null
+++ b/virtual/blas/blas-3.8.ebuild
@@ -0,0 +1,14 @@
+# Copyright 1999-2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI="7"
+
+DESCRIPTION="Virtual for FORTRAN 77 BLAS implementation"
+SLOT="0"
+KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~mips ~ppc ~ppc64 ~s390 ~sparc
~x86 ~amd64-fbsd ~x86-fbsd ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos
~x86-macos ~sparc-solaris"
+IUSE="eselect-ldso"
+
+RDEPEND="
+ >=sci-libs/lapack-3.8.0[eselect-ldso?]
+"
+DEPEND="${RDEPEND}"
diff --git a/virtual/blas/metadata.xml b/virtual/blas/metadata.xml
index 1b4d6e817c05..35dd50fb4450 100644
--- a/virtual/blas/metadata.xml
+++ b/virtual/blas/metadata.xml
@@ -6,7 +6,11 @@
Gentoo Science Project
-Gentoo virtual package for the Basic Linear Algebra Subprograms
-FORTRAN 77 implementation.
-
+Gentoo virtual package for the Basic Linear Algebra Subprograms
+FORTRAN 77 implementation.
+
+
+Enable runtime library switching by
+eselect and ld.so.
+
diff --git a/virtual/cblas/cblas-3.8.ebuild b/virtual/cblas/cblas-3.8.ebuild
new file mode 100644
index ..0b295963f8de
--- /dev/null
+++ b/virtual/cblas/cblas-3.8.ebuild
@@ -0,0 +1,14 @@
+# Copyright 1999-2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI="7"
+
+DESCRIPTION="Virtual for BLAS C implementation"
+SLOT="0"
+KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~ppc ~ppc64 ~s390 ~sparc ~x86
~amd64-fbsd ~x86-fbsd ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos"
+IUSE="eselect-ldso"
+
+RDEPEND="
+ >=sci-libs/lapack-3.8.0[eselect-ldso?]
+"
+DEPEND="${RDEPEND}"
diff --git a/virtual/cblas/metadata.xml b/virtual/cblas/metadata.xml
index 9aac1c20c93f..204ea7552ca9 100644
--- a/virtual/cblas/metadata.xml
+++ b/virtual/cblas/metadata.xml
@@ -6,7 +6,11 @@
Gentoo Science Project
-Gentoo virtual package for the Basic Linear Algebra Subprograms
-C implementation.
-
+Gentoo virtual package for the Basic Linear Algebra Subprograms
+C implementation.
+
+
+Enable runtime library switching by
+eselect and ld.so.
+
diff --git a/virtual/lapack/lapack-3.8.ebuild b/virtual/lapack/lapack-3.8.ebuild
new file mode 100644
index ..93ddd49d8b79
--- /dev/null
+++ b/virtual/lapack/lapack-3.8.ebuild
@@ -0,0 +1,14 @@
+# Copyright 1999-2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+DESCRIPTION="Virtual for Linear Algebra Package FORTRAN 77 (LAPACK)
implementation"
+SLOT="0"
+KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~ppc ~ppc64 ~s390 ~sparc ~x86
~amd64-fbsd ~x86-fbsd ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos"
+IUSE="eselect-ldso"
+
+RDEPEND="
+ >=sci-libs/lapack-3.8.0[eselect-ldso?]
+"
+DEPEND="${RDEPEND}"
diff --git a/virtual/lapack/metadata.xml b/virtual/lapack/metadata.xml
index ccb7a1fa1fad..0b91d851efe1 100644
--- a/virtual/lapack/metadata.xml
+++ b/virtual/lapack/metadata.xml
@@ -6,7 +6,11 @@
Gentoo Science Project
-Gentoo virtual package for the Linear Algebra PACKAge
-FORTRAN 77 implementation.
-
+Gentoo virtual package for the Linear Algebra PACKAge
+FORTRAN 77 implementation.
+
+
+Enable runtime library switching by
+eselect and ld.so.
+
diff --git a/virtual/lapacke/lapacke-3.8.ebuild
b/virtual/lapacke/lapacke-3.8.ebuild
new file mode 100644
index ..fc61bf733e2e
--- /dev/
[gentoo-dev] [RFC, PATCH] user.eclass: gracefully return when unprivileged
From: Benda Xu
Thanks again. I will take your original suggestion.
enewgroup and enewuser does not apply when executed as a normal
user, e.g. under Gentoo Prefix.
---
eclass/user.eclass | 8
1 file changed, 8 insertions(+)
diff --git a/eclass/user.eclass b/eclass/user.eclass
index 86bcd282479..76a622df698 100644
--- a/eclass/user.eclass
+++ b/eclass/user.eclass
@@ -103,6 +103,10 @@ egetent() {
# Default uid is (pass -1 for this) next available, default shell is
# /bin/false, default homedir is /dev/null, and there are no default groups.
enewuser() {
+ if [[ ${EUID} != 0 ]] ; then
+ einfo "Insufficient privileges to execute ${FUNCNAME[0]}"
+ return 0
+ fi
_assert_pkg_ebuild_phase ${FUNCNAME}
# get the username
@@ -262,6 +266,10 @@ enewuser() {
# do the rest. You may specify the gid for the group or allow the group to
# allocate the next available one.
enewgroup() {
+ if [[ ${EUID} != 0 ]] ; then
+ einfo "Insufficient privileges to execute ${FUNCNAME[0]}"
+ return 0
+ fi
_assert_pkg_ebuild_phase ${FUNCNAME}
# get the group
--
2.15.0
[gentoo-dev] [RFC, PATCH] user.eclass: gracefully return when unprivileged
From: Benda Xu
Thanks MJ, how about "Unprivileged to execute"? Less bytes.
enewgroup and enewuser does not apply when executed as a normal
user, e.g. under Gentoo Prefix.
---
eclass/user.eclass | 8
1 file changed, 8 insertions(+)
diff --git a/eclass/user.eclass b/eclass/user.eclass
index 86bcd282479..8ff06935277 100644
--- a/eclass/user.eclass
+++ b/eclass/user.eclass
@@ -103,6 +103,10 @@ egetent() {
# Default uid is (pass -1 for this) next available, default shell is
# /bin/false, default homedir is /dev/null, and there are no default groups.
enewuser() {
+ if [[ ${EUID} != 0 ]] ; then
+ einfo "Unprivileged to execute ${FUNCNAME[0]}"
+ return 0
+ fi
_assert_pkg_ebuild_phase ${FUNCNAME}
# get the username
@@ -262,6 +266,10 @@ enewuser() {
# do the rest. You may specify the gid for the group or allow the group to
# allocate the next available one.
enewgroup() {
+ if [[ ${EUID} != 0 ]] ; then
+ einfo "Unprivileged to execute ${FUNCNAME[0]}"
+ return 0
+ fi
_assert_pkg_ebuild_phase ${FUNCNAME}
# get the group
--
2.15.0
[gentoo-dev] [RFC, PATCH] db.eclass: support Prefix
From: Benda Xu
ROOT and D are replaced with EROOT and ED.
---
eclass/db.eclass | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/eclass/db.eclass b/eclass/db.eclass
index c46c431ea9c..0c0d0ef14cd 100644
--- a/eclass/db.eclass
+++ b/eclass/db.eclass
@@ -17,7 +17,8 @@ DEPEND="test? ( >=dev-lang/tcl-8.4 )"
RDEPEND=""
db_fix_so() {
- LIB="${ROOT}/usr/$(get_libdir)"
+ has "${EAPI:-0}" 0 1 2 && ! use prefix && EROOT="${ROOT}"
+ LIB="${EROOT}/usr/$(get_libdir)"
cd "${LIB}"
@@ -50,7 +51,7 @@ db_fix_so() {
# do the same for headers now
# but since there are only two of them, just overwrite them
- cd "${ROOT}"/usr/include
+ cd "${EROOT}"/usr/include
target=`find . -maxdepth 1 -type d -name 'db[0-9]*' | sort -n |cut -d/
-f2- | tail -n1`
if [ -n "${target}" ] && [ -e "${target}/db.h" ] && ( ! [[ -e db.h ]]
|| [[ -h db.h ]] ); then
einfo "Creating db.h symlinks to ${target}"
@@ -67,19 +68,21 @@ db_fix_so() {
}
db_src_install_doc() {
+ has "${EAPI:-0}" 0 1 2 && ! use prefix && ED="${D}"
# not everybody wants this wad of documentation as it is primarily API
docs
if use doc; then
dodir /usr/share/doc/${PF}/html
- mv "${D}"/usr/docs/* "${D}"/usr/share/doc/${PF}/html/
- rm -rf "${D}"/usr/docs
+ mv "${ED}"/usr/docs/* "${ED}"/usr/share/doc/${PF}/html/
+ rm -rf "${ED}"/usr/docs
else
- rm -rf "${D}"/usr/docs
+ rm -rf "${ED}"/usr/docs
fi
db_src_install_examples
}
db_src_install_examples() {
+ has "${EAPI:-0}" 0 1 2 && ! use prefix && ED="${D}"
if use examples ; then
local langs="c cxx stl"
[[ "${IUSE/java}" != "${IUSE}" ]] \
@@ -90,15 +93,16 @@ db_src_install_examples() {
src="${S}/../examples_${i}/"
if [ -f "${src}" ]; then
dodir "${destdir}"
- cp -ra "${src}" "${D}${destdir}/"
+ cp -ra "${src}" "${ED}${destdir}/"
fi
done
fi
}
db_src_install_usrbinslot() {
+ has "${EAPI:-0}" 0 1 2 && ! use prefix && ED="${D}"
# slot all program names to avoid overwriting
- for fname in "${D}"/usr/bin/db*
+ for fname in "${ED}"/usr/bin/db*
do
dn="$(dirname "${fname}")"
bn="$(basename "${fname}")"
@@ -109,18 +113,20 @@ db_src_install_usrbinslot() {
}
db_src_install_headerslot() {
+ has "${EAPI:-0}" 0 1 2 && ! use prefix && ED="${D}"
# install all headers in a slotted location
dodir /usr/include/db${SLOT}
- mv "${D}"/usr/include/*.h "${D}"/usr/include/db${SLOT}/
+ mv "${ED}"/usr/include/*.h "${ED}"/usr/include/db${SLOT}/
}
db_src_install_usrlibcleanup() {
- LIB="${D}/usr/$(get_libdir)"
+ has "${EAPI:-0}" 0 1 2 && ! use prefix && ED="${D}"
+ LIB="${ED}/usr/$(get_libdir)"
# Clean out the symlinks so that they will not be recorded in the
# contents (bug #60732)
- if [ "${D}" = "" ]; then
- die "Calling clean_links while \$D not defined"
+ if [ "${ED}" = "" ]; then
+ die "Calling clean_links while \$ED not defined"
fi
if [ -e "${LIB}"/libdb.a ] && [ ! -e "${LIB}"/libdb-${SLOT}.a ]; then
@@ -139,7 +145,7 @@ db_src_install_usrlibcleanup() {
find "${LIB}" -maxdepth 1 -type l -name 'libdb[1._-]*a' -exec rm \{} \;
rm -f \
- "${D}"/usr/include/{db,db_185}.h \
+ "${ED}"/usr/include/{db,db_185}.h \
"${LIB}"/libdb{,_{cxx,sql,stl,java,tcl}}.a
}
--
2.15.0
[gentoo-dev] [RFC, PATCH] user.eclass: gracefully return when unprivileged.
From: Benda Xu
enewgroup and enewuser does not apply when executed as a normal
user, e.g. under Gentoo Prefix.
---
eclass/user.eclass | 8
1 file changed, 8 insertions(+)
diff --git a/eclass/user.eclass b/eclass/user.eclass
index 86bcd282479..82ccc1100ac 100644
--- a/eclass/user.eclass
+++ b/eclass/user.eclass
@@ -103,6 +103,10 @@ egetent() {
# Default uid is (pass -1 for this) next available, default shell is
# /bin/false, default homedir is /dev/null, and there are no default groups.
enewuser() {
+ if [[ ${EUID} != 0 ]] ; then
+ einfo "Donot have enough privilege to execute ${FUNCNAME[0]}"
+ return 0
+ fi
_assert_pkg_ebuild_phase ${FUNCNAME}
# get the username
@@ -262,6 +266,10 @@ enewuser() {
# do the rest. You may specify the gid for the group or allow the group to
# allocate the next available one.
enewgroup() {
+ if [[ ${EUID} != 0 ]] ; then
+ einfo "Donot have enough privilege to execute ${FUNCNAME[0]}"
+ return 0
+ fi
_assert_pkg_ebuild_phase ${FUNCNAME}
# get the group
--
2.15.0
Re: [gentoo-dev] Re: [gentoo-dev-announce] Service relaunch: archives.gentoo.org
"Paweł Hajdan, Jr." writes: > Awesome work! > > I was always proud about Gentoo's mailing list archives - no spam, > simple UI. > > Just wanted to say thanks to a3li, and entire Infra team. Oh, and the > new design looks great. Second that. Thanks a3li and infra. Good job. BTW, I love the links of "Find on GMANE/MARC". Benda pgpHFKEHH3Fc6.pgp Description: PGP signature
[gentoo-dev] Re: RFC: Project Android
Hi Ciaran, Ciaran McCreesh writes: > On Sat, 22 Nov 2014 22:58:17 +0900 > hero...@gentoo.org wrote: >> It strives to liberate the computers in our pockets with Gentoo >> philosophy and style, as an ultimate response to Free Software >> Foundation(FSF)'s concerns on the freedom for mobile computing. > > Not sure if serious... Yes, it is serious. Software has a lot of flexibility for alienation. When a mobile device gets more powerful, more of its logic is encoded by software. In consequence, it is more likely to be used as a tool to control and sabotage its users. Some vendors do release the source code. But the problems are, 1. lack of important instructions to reproduce the running system from the code 2. devices with tivoization only boots signed kernels 3. binary bolbs are needed to talk to specific peripherals The project, from Gentoo point of view, attacks these problems by, (1.) using ebuilds to document the build instructions, (2.3.) providing run-time tools to reverse-engineer the offensive mechanisms. Cheers, Benda pgpD3JQ877ypU.pgp Description: PGP signature
[gentoo-dev] RFC: Project Android
Dear fellows, I have updated the project page of Android at: https://wiki.gentoo.org/wiki/Project:Android to convey the purpose and methodology of the project to the public. To quote: This project is about bringing Gentoo users and develops home to their mobile devices. It aims to produce an environment that is indifferent to that of desktop computers. It strives to liberate the computers in our pockets with Gentoo philosophy and style, as an ultimate response to Free Software Foundation(FSF)'s concerns on the freedom for mobile computing. If you are interested, please share your ideas and consider to join in the effort. I would also like to have some help to polish the text to make it more objective, neutral and Gentoo-centric. Thank you very much. Cheers, Benda
Re: [gentoo-dev] Re: The state and future of the OpenRC project
Alexey Shvetsov writes: > However this will depend on migration of gentoo-x86 to git Well, we can start evaluating gitlab for git overlays and gentoo hosted projects, such as (back to topic :) OpenRC. Is the infra team interested in this option? pgpqPDX0LzcUz.pgp Description: PGP signature
Re: [gentoo-dev] The state and future of the OpenRC project
Alexander Berntsen writes: > It would be cool if some of the OpenRC hackers had the time to set up > a developer's wiki or similar, where they share their workflow and > similar. Nice idea, on my list. pgp5kJikw7nfi.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: Hosting daily gx86 squashfs images and deltas
Alex Xu writes: > This doesn't really help. Consider that deltas require both a *start* > and *end*. It's not as simple as adding it all up, since you would need > a 19-3d, then 3-1d, then 1-0d. In this case, 19-18d, 18-16d, 16-0d, instead. The largest delta is always used for the most recent. That's why we need 8 pieces of 2d delta and 16 pieces of 1d delta. pgpkuCRmXKr7o.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: Hosting daily gx86 squashfs images and deltas
Michał Górny writes: > However, it may be actually beneficial to provide other durations, like > weekly deltas. In my tests, the daily updates for this week summed up > to almost 50M while the weekly was barely 20M. Is there a way to merge the deltas without the original squashfs? how fast is the delta generation? It could be done on the server side on the fly and cached. Or we provide a set of 16,8,4,2,1 day deltas, then 16d: 1 piece needed 8d: 2 needed 4d: 4 needed 2d: 8 needed 1d: 16 needed The total of 31 pieces will cover a month (31 days) with at most 5 deltas to be downloaded. e.g. If the system is 19 days old, then we download a 1d, 2d, and 16d. Cheers, Benda pgpS54FnX5ALN.pgp Description: PGP signature
Re: [gentoo-dev] Re: Portage QOS
Duncan <1i5t5.dun...@cox.net> writes: > Meanwhile, you might try googling Zynot. That was one early, perhaps the > first, Gentoo fork. Such talk of cutthroat competition in a zero-sum > game, of deliberately cutting off user options so they'd be forced to > stick with you, of it can be us or them, not both, etc, was exactly the > sort of thing they tried. That was 2002/2003 or so. While the events > and acrimony surrounding that did ultimately drive Gentoo's founder > (Daniel Robbins) elsewhere, Gentoo survived (thanks in part to drobbins' > efforts to secure a good future for it even at heavy personal cost to > himself and his family as he was already in the process of leaving). > Gentoo's still here, but where is zynot today? > > I remember back in early 2004 as I was researching my switch to gentoo, > reading up on zynot, which was at that time still a going concern, and > repeatedly asking myself as I read the essays from zynot's founder > heavily criticizing gentoo and its founder, why can't he see what's > happening, that every single thing he's negatively pointing at in gentoo > and drobbins he and zynot are doing themselves in far greater measure, > and why he was so stuck on closed source competitive techniques in an > open source world. His very essays, supposedly criticizing gentoo, > instead ended up convincing me more than ever that gentoo was /exactly/ > the right choice for me. =:^) Wow... What a history! I am educated. Thanks for sharing. I've always been interested in my distro's history. The information scatters here and there. It'll be nice if some senior/retired developers write up a Gentoo history on wiki.g.o :) Benda
Re: [gentoo-dev] Portage QOS
Hi Igor, Igor writes: > I've been using C/C++ since school it's fast, even bad code is working fast. > > I WOULD NEVER BELIVE PYTHON IS AS FAST AS C++ with math algorithms > that do calculate staff and not call functions from pre-complied > objects written in C/C++. > > It's crazy that you're even trying to state it. Take a look at what > Python is producing in disasm and then look at it in G++. > >>> So why do we send Gentoo for food riding on Python? If it were death >>> we send Gentoo for then I would choose Python but food? > >> I'm finding it very hard to stay polite, because ... honestly? >> You have no idea what you're talking about. > > Or vice versa. > >> If you want things to change - hire a few of us fulltime to work on >> things, and you'll get the change you want. >> Until then there's no need to point out that we are lacking manpower to >> do large-scale changes, because that's been a constant in most >> opensource projects since the 1960s. > >> Less talking, more doing - provide patches and stop polluting our >> mailing list with your madness. > > See tge subject of this letter. The whole point of this conversation is that > I offered to design it and program it and offered HARDWARE for it but we > can't get to the point because it's not clear for everyone if we need it. > > If high command not needing it it will find means to kill it and I'm > very busy, really very busy - can't afford to spend that much time on > something not useful. I appreciate your intension to make Gentoo better, at the same time I could not share the view with you. Here is the checklist for you: 1. I got a brilliant idea! goto 2 2. Can I realize it by myself? Y, goto 6; N goto 3 3. Can I convince someone to do it for me? Y, goto 6; N goto 4 4. Can I hire someone to do it for me? Y, goto 6; N goto 5 5. Nothing could be achieved :( 6. After rounds of hard work, it comes true :D Seems that you got stuck at 5. Sorry if you are not willing to adjust your attitude, your subsequent will be ignored. Some of the details of your proposal do interest me, such as an automatic build.log / emerge --info uploader. Supporting mail reply to bugzilla will even be cooler (which can be used to upload build.log and emerge --info of course). Cheers, Benda
Re: [gentoo-dev] Portage QOS
Tom Wijsman writes: >> I am curious about the slowness of emerge. > > Try a --backtrack=0 approach, I no longer need to increase it. :) on a random box: time emerge --backtrack=0 -pe @world [...] real0m30.016s user0m29.268s sys 0m0.704s time emerge -pe @world [...] real0m35.037s user0m30.824s sys 0m1.136s not a big difference? >> How about profile the portage and rewrite the time-crucial part in >> C/C++, or ideally, borrowing the counterpart from paludis? How >> feasible is that? > > http://dev.gentoo.org/~tomwij/files/portage-2.2.7-python-2.7-backtrack-0.png > http://dev.gentoo.org/~tomwij/files/portage-2.2.7-python-2.7-backtrack-0-hot.png > http://dev.gentoo.org/~tomwij/files/portage-2.2.7-python-3.3-backtrack-0.png > > (hot is the hotshot profiler, it internally checks on the line level > instead; 3.3's profiler is obstructed by module loading, no idea why) Great! That's what I am looking for. pgp2YrVrzkrgG.pgp Description: PGP signature
Re: [gentoo-dev] Portage QOS
Patrick Lauer writes: > For python things you really want python or C instead of C++... Well, we have boost-python to do python extensions in C++. And yes, introducing boost as a dependency to portage is not cool. >> I guess the dep-tree calculation is the slowest part. > Yes, it's doing lots of silly dynamic things (backtracking), and > portage codebase on average is not designed for speed. > > As a first step I would recommend profiling it and removing unneeded > stuff (do less work!), rewriting parts in C is a lot of work and not > needed for the first round of speedups. Cython[1] can be used to generate C code quickly to avoid spending to much time coding in C. 1. http://www.cython.org
Re: [gentoo-dev] Portage QOS
Hey Igor, Igor writes: > Jeroen, tell me how many users world wide do not prefer to upgrade Gentoo > on automated basis? There are important servers, and there are many > cases when after upgrade server stops. Do you remember that recent udev > change? And there are many similar cases. Imagine that your server > is running a reactor. So what would you prefer to keep it running the > reactor as it did flawlessly for 8 years or launch an upgrade taking > the risks to blast yourself? > > Many be it's not only me, but somebody else who is thinking the same? > Are you sure that the majority of Gentoo users are indulged in > paranoid automated upgrade and then spending time fixing damage > that upgrade did? > > Do you have a car? Why you don't change EVERY detail in your car on a new > version on daily basis automatically? > > Why don't you change car as soon as a new version is released? Why not > changing the new mouse, new keyboard, new monitor, new supply daily as > soon as there is a new version? > > Not to mention that you can change daily appearances. IMHO, the bleeding-edgeness and stability form a balance. We cannot achieve both. Taking RHEL for example, it uses ancient software for the sake of stability. Gentoo is way off the other extreme. For the udev change, the upstream has been doing evil and eudev is not introduced as the default for Gentoo (yet). New software breaks things, and security-updated old software needs extra care: That's the fundamental problem we couldn't circumvent. Cheers, Benda
Re: [gentoo-dev] Portage QOS
Igor writes: > The ebuilds have approximately the same time to install, the failure > rate is about the same, emerge is getting slower. I am curious about the slowness of emerge. How about profile the portage and rewrite the time-crucial part in C/C++, or ideally, borrowing the counterpart from paludis? How feasible is that? I guess the dep-tree calculation is the slowest part.
Re: [gentoo-dev] How to support C++11 in libraries?
Michał Górny writes: > Think of paludis as a good example. People who'd like to use Paludis > will end up with broken package manager from time to time. How are they > supposed to rebuild it without a working package manager? Oh, I'm scared. I'll step away and watch out for such situation at all cost. pgpvmL8zTx8IU.pgp Description: PGP signature
Re: [gentoo-dev] How to support C++11 in libraries?
Michał Górny writes: > And that brings another issue in Gentoo -- gcc-config. AFAIR this tool > is completely insane and switches libstdc++ along with gcc version. > As a result, after switching to a gcc version with different C++ ABI, > installed software gets broken. And you can't really fix it without > going through the broken-system state or some hackery. Not that insane. Packages linked with libstdc++ are not crucial in Gentoo, and can be rebuilt with emerge -e @world. Although it's a bad idea for everybody to do so, the systems without "emerge -e @world" for two years is likely to suck anyway. It just reflects the fact that the world is not perfect. pgp5ze1bLsmnb.pgp Description: PGP signature
Re: [gentoo-dev] How to support C++11 in libraries?
Michał Górny writes: > This is nowhere near a good solution IMO. > > First of all, it doesn't give us a way of ensuring ABI compatibility. > Users switch the flags and have to rebuild all C++ packages to regain > the ABI compatibility. The system ends up borked quite easily. > > Then, we don't have a good way of finding packages to rebuild. Users > could try to find out which libraries used C++ but well... it's nowhere > near good. Or they just rebuild everything... > > Then, many developers just won't bother. Users will be the ones to hit > the incompatible package build failures first. > > Lastly, this gives us no way of switching to C++11 completely without > modifying the compiler defaults. Even if we put '-std=c++11' into > profiles, most of the people override CXXFLAGS and won't have it. > >> Any anyway, if it is only for lldb, a piece of elog conveying a >> preferred solution would suffice. > > elog? I think you mean dying with CXXFLAGS that don't specify > the necessary standard. Which is kinda backwards to REQUIRED_USE... > > And then, simple CXXFLAGS solution would end up breaking users' > systems... Michał, I am totally agree with you. This approach will leave lots of dirty tricks to the users. Therefore this is a decision between whether the devs or the users do this heavy lift. If the the reason is only lldb and less than 10 other ebuilds, I feel it not worth the develop and maintenace time. And if you have only met with this problem twice, I suggest playing with it by the simplest solution (via CXXFLAGS) for a while to avoid early optimization. This is just my honest view on simple vs complex. Given the expertise you hold in the realm of ABI, introducing a new ABI to maintain might not be a big deal to you. Then I understand. Cheers, Benda pgpiPL6Z_CKNV.pgp Description: PGP signature
Re: [gentoo-dev] How to support C++11 in libraries?
"C. Bergström" writes: > "Best case" both build and you end up with a linker problem (can be > worked around with compiler patches) > /usr/lib64/libboost.so > /usr/lib64-c++11/libboost.so This is the right way to do, but as scary as our multilib where a couple of USE flags are introduced to every package globally.
Re: [gentoo-dev] How to support C++11 in libraries?
Hey Jan, Jan Kundrát writes: > This perspective is interesting (and I admit that I tend to like it) -- > considering packages which won't build with C++11 to be buggy. > > I'm worried by the cost of such a policy, though, because we would > suddenly have to patch some unknown amount of software (and I'm pretty > sure some upstreams would reject these patches anyway). If we were an > enterprise distro with binary compatibility requirements, we would > also have to worry about that and either assume that the ABI changes > are non-issue in real world, or provide two versions of all C++ > libraries. I tried to check how RHEL7 will deal with it, but I wasn't > able to find any information about that. It also seems that Fedora > hasn't addressed this yet, either. > > Either way, it is reasonable to assume that some users would like to > build their own software and link it with system libraries. It is not > reasonable to force these users to build in the C++11 mode, IMHO. I'd like to make an analogy to the version bump of gcc[1]. We (gentoo) decide to support c++11 officially or not. If so, open a tracker bug to push it globally. If not, patch lldb to support non-c++11, or leave it up to the user to fiddle with the CXXFLAGS, where we only point the user by to proper docs. There is no problem to introduce a new USE flag for a new ABI. I am concerned with too many ABIs for an average ebuild keeper to maintain. Benda 1. https://bugs.gentoo.org/show_bug.cgi?id=gcc-4.8
Re: [gentoo-dev] How to support C++11 in libraries?
Hey, Michał, Michał Górny writes: > a) adding USE=c++11 and USE-deps to all the packages in question, I think it is better achieved by a (simple and stupid) global CXXFLAGS. Adding an extra USE flag feels a little over-engineering. Any anyway, if it is only for lldb, a piece of elog conveying a preferred solution would suffice. > b) doing the switch via synchronous version bump and matching > dependencies. This sounds tedious to maintain. Benda pgpdHEtePjCLe.pgp Description: PGP signature
Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?
[reordered to ease replying] Rich Freeman writes: > Now, perhaps a more balanced approach might be to mask it and give 15 > days notice on -dev, and then it can be unmasked. Anybody who cares > about the library can test the new version, and if necessary update > their dependencies to use the previous slot only (and if 15 days isn't > enough time they can just update the dep right away and then update it > again after they get around to testing it). Those who don't want to > have to deal with that can just define their slot dependencies > explicitly so that this policy will never apply to them. Good idea! > The problem with this is that it puts the onus on the person who wants > to make forward progress (adding support for a new library version). > That means that they have incentive to either not bother with the new > library version (causing Gentoo to stagnate), or use hacks like giving > the library a new name (which we have examples in the tree of). > In order for a QA policy to be effective it has to either be minimally > intrusive, or make the cost of compliance lower than the cost of > workarounds or benign neglect. People don't HAVE to maintain > packages, after all... I agree with that. We are all aware that every gcc slot bump costs so much work (and frustration). At the same time, it worth the hard work for a well-organized tree and flexibility. The only draw back is lack of man power to do it right like bug 493652. Yes, when a library introduces a new not fully compatible version, it naturally implies a lots of work to do for downstream like us. There is no escape: If we hack a versioned library name, it will bite us in the future. The question becomes: Who should do this heavy lifting? This is a glitch in the amount of work needed when a single-slotted library suddenly becomes slotted. IMHO, let's form a slotting group in the reformed QA team who will donate manpower for such situation to aid the library maintainer. Anyone who wants to make forward progress but does not have enough time seeks help to the slotting group. What do you say? Benda
Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?
Rich Freeman writes: > A new slot of a package (which doesn't exist today) may or may not > work with any ebuild in the system. Should it be considered a best > practice then to specify || deps with all slots that are known to work > in the tree? Or should we just trust to luck and consider it > acceptable for maintainers to add new slots of commonly-used libs and > users and downstream maintainers can deal with the resulting breakage? > > Library maintainers don't seem to like dealing with that, so they just > stick new slots in an entirely new package, and then we end up with > all the || dependencies anyway and we make no use of the nice slot > syntax because it is prone to breakage. > > It seems like the current way we handle slots for dependencies works > just fine until somebody actually tries to introduce a new slot for a > package, and then a whole pile of assumptions comes crashing down. How about defining a QA workflow for introducing a new slot of a library, such as "mask it and open a tracker bug until every individual reverse dependencies are checked"? Benda
Re: [gentoo-dev] python versioned libraries or not
yac writes: > Shouldn't pkg-conifg --libs handle this? Oh, good idea. But boost doesn't have pkg-config entries. Then I see this one, an upstream issue https://svn.boost.org/trac/boost/ticket/1094 Thanks. pgpf7FoU2HZeq.pgp Description: PGP signature
[gentoo-dev] python versioned libraries or not
Dear all,
I have only one python-2.7 on my system. Simple and stupid.
After boost ebuild is converted to python-r1, libboost_python.so is
renamed to libboost_python-2.7.so. This is all cool about python-r1 for
multiple python implementation support.
At the same time, I don't need this feature. I have a couple of
Jamroot's which append "-lboost_python" to LDFLAGS, and I have to
manually specify "-lboost_python-2.7". Moreover, libraries depending on
boost.python, e.g. Boost.NumPy[1], searches for boost_python and
boost_python-mt only. I am forced to patch the build system to pass
"-${PYVAR}" to it, which is tedious.
I am looking for a way out. Candidates are,
1. scan all python versioned libraries and symlink them to
unversioned one. Question: hints to do it systematically in
portage? Is there a helper available like python-exec?
2. python-single-r1 is ready for use, but it requires manipulating
the boost ebuild to change from python-r1, if I want a
python-single-r1 blessed boost. Question: How about merging
python-single-r1 with python-r1 and controlling by a global USE
flag "python-single". When "python-single" is set, all ebuilds
inheriting python-r1 behaves as if being with python-single-r1,
so that all python versionings on executables and libraries are
disabled.
3. or something I missed
Comments?
Benda
1. https://github.com/ndarray/Boost.NumPy
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
Johann Schmitz writes: > Is it possible to run, say, mips on xen/whatever through some > emulation layer or is real hardware a requirement for this archs? Yes, via qemu. But very slow, nearly unusable even on a powerful mainstream amd64 server.
Re: [gentoo-dev] Suggestion: support the Dev team with system resources
Dear Denis, "Denis M." writes: > Please review this, and if you agree that it'd be a good idea come > with any suggestions to make it happen as well as with any other > thoughts/sys-specs/instances we should be looking for. Thanks for the offering. Though not a member, AT teams might benefit from such a build farm. What are you suggesting practically, making a policy for everyone to donate VM to Gentoo, or developing a midware to do so? Cheers, Benda
Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec
Alan McKinnon writes: > One set of questions that were never answered and probably do deserve > some kind of notification: > > 1. What exactly is python-exec anyway? > 2. Why are there two, in dev-python/ and dev-lang/ ? > 3. One has a version of -1, which is *highly* unusual, what is that > exactly? 1 more than -? > 4. There is some kind of migration going on between an old and new > python-exec, but I can't understand it using only standard portage tools. I can resonate with these questions. I bet it's common for people outside the python herd.
Re: [gentoo-dev] desktop experience on smartphone: thoughts and plans against Ubuntu edge
Hey Chris, Chris Reffett writes: > Indeed I have. If you want to start such a project, I would certainly > be interested in joining. Plasma Active is basically untested because > I don't have a mobile device with Gentoo and installing it on a normal > computer leads to display sizing issues, but I welcome any suggestions > or bug reports you have for that. Great idea. As qt4 already supports wayland, we'll head to Plasma Active as soon as we have a wayland. Unfortunately at present, we have no code for graphics at all. It might take long. > What I would really like to see come out of this is some pre-made > Gentoo stage4s for different kinds of devices, which I think would be > a big draw for users. Yeah, https://wiki.gentoo.org/wiki/Project:Android/tarball serves the purpose. Cheers, Benda
Re: [gentoo-dev] desktop experience on smartphone: thoughts and plans against Ubuntu edge
Hey Alexey, Alexey Mishustin writes: > My rooted Samsung Galaxy S2 is also ready to receive and to test this > kind of Gentoo. Sorry for being slow. I made it finally. Would you like to test it on your favorite Galaxy S2? https://wiki.gentoo.org/wiki/Project:Android/tarball Also, feel free to append it to the device list https://wiki.gentoo.org/wiki/Project:Android/devices Cheers, Benda
Re: [gentoo-dev] Gentoo Upgrade Guide and EAPI
"Rick \"Zero_Chaos\" Farina" writes: > While I'm not nearly good enough to detail how this should happen > exactly, please, may I beg, do an eclass revision for this. There is an r1 candidate as Paweł initiated (bug 474358) > The fact that this hasn't been done clearly implies it is a lot of > work. Let's not risk stable, let's simply make toolchain-r1.eclass or > whatever, and bump that to eapi5. At the end of the day, this allows > working and testing without odd issues, and if everyone really hates > that idea you can simply drop the changes into the original eclass > when it's all done. Having a unstable eclass as toolchain-r1.eclass in tree might not be a good idea compared to an overlay though. Regarding eclass, I have a question: Why do we keep all old versions of gcc and glibc? If the point is only being upgradable from old Gentoo, is the requirement lefted now? If it is for users who need a specific version of gcc/glibc, why don't we create a toolchain-archive overlay for that purpose? In the overlay we can have historical snapshots of toolchain.eclass, too. Keeping only a few version of gcc in tree will ease the maintenance of toolchain eclass a lot. Benda
Re: [gentoo-dev] Gentoo Upgrade Guide and EAPI
"Rick \"Zero_Chaos\" Farina" writes: > On 09/28/2013 03:00 AM, Ulrich Mueller wrote: >>>>>>> On Sat, 28 Sep 2013, heroxbd wrote: >> >>> I am revisiting this topic based on previous discussions[1,2,3]. >> >>> There seems to be a constant need for toolchain with a new EAPI. The >>> only block is "how can we upgrade from an ancient system?", "don't >>> bump or the upgrade path will be break". Let's figure out a solid >>> upgrade path consciously, with a test farm of ancient systems, and >>> then bump the EAPI of toolchain. >> >> The upgrade path is not at all what is blocking this. In its 20130409 >> meeting, the council has (unanimously) decided: "EAPIs 0 to 2 are no >> longer required for the upgrade path of users' systems." >> >> The reason why toolchain packages are still at EAPI 0 was explained in >> this posting: >> http://thread.gmane.org/gmane.linux.gentoo.project/2369/focus=2377 >> >> AFAICS, changing that is entirely the task of the toolchain team. Thank you for the clarification, Ulrich. > Yes, it is entirely the task of the toolchain team, and looks like > heroxbd joined the toolchain team and would like to push the rest of his > team for this update. Something I greatly thank him for. > > I don't think any dev wants to (or really could) force toolchain to > update individually, however, if motivated people want to join the team > and help, his question appeared to be will it be permitted to be > updated. Can't agree with you more. It's just a starting point, though. I still don't have a clear plan yet. After reading carefully the thread Ulrich pointed out, it seems that refactoring ebuild/eclass is invevitable, which calls for an overlay to carry it on. Benda
[gentoo-dev] Gentoo Upgrade Guide and EAPI
Dear Fellows, I am revisiting this topic based on previous discussions[1,2,3]. There seems to be a constant need for toolchain with a new EAPI. The only block is "how can we upgrade from an ancient system?", "don't bump or the upgrade path will be break". Let's figure out a solid upgrade path consciously, with a test farm of ancient systems, and then bump the EAPI of toolchain. Besides the upgrading guide[4] suggesting a chroot, rich0 had some experiences with a live overwriting of latest stage3 to /, recently I've heard from patrick of a script to bootstrap Gentoo lively on an existing system (be it Debian, Red Hat or an ancient Gentoo). Here is another alternative from Prefix (upgrading the kernel is mostly independent): a. we distribute a stage3 of Gentoo RAP(i.e. Prefix with libc), with EPREFIX pointing to, say, /tmp/upgrade b. sync the potage tree in the host system, switch it to the newest profile. c. PORTAGE_OVERRIDE_EPREFIX=/ /tmp/upgrade/usr/bin/emerge -e world It has the same solidity as the chroot while being easier without the need to mount back and forth. It can track installed files properly as opposed to overwriting /. This needs a lot of work to do the testing. At the same time, there are definitely a dozen of developers who want to bump the EAPI of toolchain. Let's share the workload. vapier, if we can figure out a solid and easy solution for upgrading ancient Gentoo, would you agree on bumping the EAPI of toolchain? Cheers, Benda 1. http://thread.gmane.org/gmane.linux.gentoo.devel/86803 2. http://article.gmane.org/gmane.linux.gentoo.devel/73767 3. http://article.gmane.org/gmane.linux.gentoo.project/2841 4. http://www.gentoo.org/doc/en/gentoo-upgrading.xml
Re: [gentoo-dev] markdown docs like README.md
hasufell writes: > I wonder if it would make any sense to take the effort to convert > markdown docs to html format before installing them. I'd rather leave it alone, as markdown is more readable than html, IMHO. Anyway, when we read html in the console, it's converted back to plan text.
[gentoo-dev] Reference Implementation for GLEP RAP Draft
Dear all, We have just pushed out a reference implementation for GLEP RAP (i.e. Prefix with libc) draft: http://article.gmane.org/gmane.linux.gentoo.alt/6663 Hope this will help people grab the idea behind it and help the council review and decide on the GLEP draft[1]. At the moment, amd64, x86 and arm running Linux are supported. Cheers, Benda 1. http://article.gmane.org/gmane.linux.gentoo.project/3023
Re: [gentoo-dev] Moving more arches to dev profiles
Markos Chandras writes: > I propose the following arches to lose their stable keywords > > - s390 > - sh > - ia64 > - alpha > - m68k > - sparc I support this proposal. I only have an old sparc box at hand. They are no longer major as time goes, IMHO.
Re: [gentoo-dev] desktop experience on smartphone: thoughts and plans against Ubuntu edge
Dear Arun, Arun Raghavan writes: > None of these worked for you? https://wiki.ubuntu.com/Touch/Install > > I believe there were efforts to port to arbitrary non-Nexus devices as > well. Ah, get to understand what you have meant. I was not talking about replacing mobile devices with a GNU/Linux, not even dual booting. It was running GNU in parallel to Android, sharing the same Linux kernel and hardware, cooperating with each other. Cheers, Benda
Re: [gentoo-dev] desktop experience on smartphone: thoughts and plans against Ubuntu edge
Arun Raghavan writes: > There are images available for this, btw, if you want to see how it > works and poke around. I'd seen some repositories, but don't know if > there's enough public to do your own build. I am very interested in such an image. Would you please dig out a link for me? I searched the web in vain. >> As a natual consequence of the on-going Google Summer of Code project, >> Gentoo on Android[3], we can run native Gentoo on *all* the Android >> devices. Compiling out an Xorg and output to HDMI has no theoretical >> difficulty. Furthermore, sharing of graphic output with Android (instead >> of a separate HDMI output) can be explored with wayland x11[4]. > > There are a lot of _hard_ problems here (display, audio, input, > codecs), not to even begin on proper policy integration (your phone is > hooked up, voice call starts, what do you do). Yes, you're right. > That's not to discourage your effort at all - I think it's great that > you're kicking this off and that there is so much enthusiasm for this. > I look forward to seeing the solutions that emerge to solve all of > these, and am happy to offer to test on a device or two. I'd make it incremental, by releasing only a full Gentoo environment (Gentoo RAP) as the first step. Then base on that, gather forces to attack the hard(-ware) problems you mentioned. Cheers, Benda
Re: [gentoo-dev] desktop experience on smartphone: thoughts and plans against Ubuntu edge
"Rick \"Zero_Chaos\" Farina" writes: > You know what I've done with this kind of thing already. I am at your > disposal. If you want to publicly embarass canonical by releasing > something awesome (either first or better) I can find the time to help. > You know where to find me ;-) That's great, Rick! Come and add yourself here, http://www.g.o/proj/en/gentoo-alt/android/index.xml The page calls for extra love to be expanded. See you in the usual place! Benda pgpL0o5WyovfB.pgp Description: PGP signature
Re: [gentoo-dev] desktop experience on smartphone: thoughts and plans against Ubuntu edge
Alexey Mishustin writes: > My rooted Samsung Galaxy S2 is also ready to receive and to test this > kind of Gentoo. Will be important the version of Android installed? No, it would be agnostic to Android versions. CPU of Galaxy S2 belongs to armv7a hardfloat, which is our main release target. Just a minute, I'll release a stage3 tarball. Benda
Re: [gentoo-dev] desktop experience on smartphone: thoughts and plans against Ubuntu edge
"Andreas K. Huettel" writes: > while I won't have the time to contribute much, I would like to tell you that > this is definitely a very cool and worthwhile project! I think you should > make > a project page and sign yourself up as team lead immediately... :) Thank you, Andreas. I've started a subproject here, http://www.gentoo.org/proj/en/gentoo-alt/android/index.xml > Chris Reffett from KDE team has done already a lot of work on packaging > Plasma > Active, see http://plasma-active.org/ - it's in the KDE overlay but mostly > untested so far. You might be interested! Talked to him on IRC. Thanks for the info. Benda pgpj9mqlWvjFP.pgp Description: PGP signature
Re: [gentoo-dev] desktop experience on smartphone: thoughts and plans against Ubuntu edge
Samuli Suominen writes: > Does gpe-base/* and gpe-utils/* relate to this at all? Somehow. Just as Plasma Activity, it could be used as a GUI but not necessarily. Benda
Re: [gentoo-dev] desktop experience on smartphone: thoughts and plans against Ubuntu edge
"Paweł Hajdan, Jr." writes: > Sounds good. Note that it doesn't need to be set up as "against > Canonical". Just do the best thing for the users. Thanks. I'd take your advice. >> I would like to kick out a sub-project of Gentoo targeting smartphone >> and tablets. It would be nice to find out a solution based on Gentoo >> for desktop/smartphone hybrid *before* Canonical's release. > > Everybody can create a sub-project, and I'm happy to see this kind of > project appearing in Gentoo. > > I'd recommend focusing on creating a good, compelling experience, not > just pushing out something before Canonical. :) Yes, I agree. pgpVnDXtIHVc5.pgp Description: PGP signature
Re: [gentoo-dev] desktop experience on smartphone: thoughts and plans against Ubuntu edge
Daniel Campbell writes: > I'm not a developer but this project's existence would motivate me to > get a compatible smartphone and test this new Gentoo version on it, > assuming it's also capable of standard phone calls and texts, etc. This assumption certainly holds firm. It is firstly a phone and then a computer.
Re: [gentoo-dev] Re: RFC: GLEP rap (Prefix/libc)
Dear Duncan,
Duncan <1i5t5.dun...@cox.net> writes:
> heroxbd posted on Mon, 12 Aug 2013 16:45:56 +0900 as excerpted:
>
>> I have made a GLEP draft to standardize our recent effort on using our
>> own libc from portage inside Prefix.
>>
>> At present only glibc on linux is supported.
>>
>> The rst text are included inline.
>
> Hi. I know nothing about prefix so won't attempt a comment on that.
> There were, however, just a few sentences that did not read very smoothly
> to me as a native English speaker, so here are some (relatively minor)
> suggested changes. Mostly, I'm simply adding a few "the"s and changing
> verb tense in a few spots, but there's a couple sentence splitting/
> combining/rewording suggestions as well.
Your linguistic suggestion is very much appreciated! I could never find
out these natural rephasing by myself.
I have applied all and tracked it with a git repo:
http://git.heroxbd.z.tuna.tsinghua.edu.cn/?p=doc.git;a=commitdiff;h=aa51133
>> Motivation ==
>
> ...
>
>> RAP
>> Literally means *Rap Ain't Prefix*. It serves as an acronym of
>> *Prefix with libc* and is used interchangeably in this GLEP.
>>
>> Userspace of RAP is identical to Gentoo Linux, therefore more uniform
>> and robust. RAP helps the ongoing effort of merging prefix and gx86
>> portage trees [#pgx86]_.
>
> THE userspace of RAP is ... (Insert "The". I'll use ALL CAPS to denote
> most of my changes.)
Applied.
> Kudos for the self-referential name, BTW! =:^)
Thanks :D
>> Thanks to the completely independent userspace, RAP can run on any
>> kernel that glibc was ported to
>
> ... that glibc HAS BEEN ported to ... (not was)
Applied.
>> Rationale =
>>
>> Gentoo Linux, though often cited as *metadistribution*, originates from
>> a Linux distribution. Linux is supported better in Gentoo. In Prefix
>> community, the merging of prefix and gx86 portage trees [#pgx86]_ is
>> brought back by non-Linux systems such as Mac OS X and Solaris.
>
> This paragraph read really rough for me, likely even more so as I'm not
> familiar enough with prefix to be sure what you're actually trying to
> say. However, this is my best guess (again, changes in ALL CAPS):
>
> ... originatED AS a Linux distribution, AND Linux REMAINS BEST
> supported. In THE Prefix community, ...
>
> (Put "originated" in past tense. Replace "from" with "as". Merge the
> two sentences using "and" and reword slightly since the second is so
> closely related to the first. "The" prefix community...)
Applied
> I /believe/ there's a further problem later in that sentence (... is
> brought back...), but I'm simply not familiar enough with prefix to have
> a clue what the intended meaning was or to suggest better wording.
> Hopefully someone else with better knowledge of the domain can suggest
> something... or confirm that it's fine as-is and I simply didn't know
> what I was talking about.
non-Linux platforms like Mac OS X requires larger maintenance love than
its Linux conterparts. The same is true for porting non-Linux back to
gx86. The present effort merging Prefix overlay treats non-Linux and
Linux equally, with the developers' time most spent on non-Linux. In the
sense Linux is much easier to be merged, it is brought back by non-Linux
ones.
>> Backwards Compatibility ===
>>
>> RAP cannot be mixed with present Prefix Linux implementation based on
>> rpath if version of the host glibc is too low.
>
> ... cannot be mixed with THE present ... based on rpath if THE version
> of...
Applied.
>> Specification =
>>
>> Present Prefix Linux uses *rpath mechanism* [#rpath]_, namely encode a
>> prefixed library path into RPATH and RUNPATH in dynamic section of ELF.
>
> PresentLY, Prefix Linux uses THE *rpath mechanism* [#rpath]_. Namely,
> encode a prefixed library path into RPATH and RUNPATH in THE dynamic...
>
> ("PresentLY", comma. Add a couple "the"s. If you keep "namely", split
> the sentence in half.)
>
> Another alternative (the way I'd likely word it myself) would change the
> tense to "encoding" and skip "namely":
>
> Presently, Prefix Linux uses the *rpath mechanism* [#rpath]_, encoding a
> prefixed library path into RPATH and RUNPATH in the dynamic...
Adopted the second.
>> RAP, on the other hand, encode a prefixed dynamic loader into INTERP in
>> the program header of ELF.
>
> RAP, on the other hand, ENCODES a prefixed dynamic
[gentoo-dev] desktop experience on smartphone: thoughts and plans against Ubuntu edge
Dear Fellows, Canonical is raising money by pushing their concept of Ubuntu for Android[1][2]. The idea is to put GNU environment (esp. Ubuntu userland) in parallel to Android to drive the external HDMI output with X11 protocal, so that desktop applications can run on the smartphone. The idea is cool, but not new. The idea is general to all android devices, while Canonical is binding the concept with its own new device. The project is developed underground by Canonical, so far nothing, not to say repository, is available except advertisements and the call for people to donate. As a natual consequence of the on-going Google Summer of Code project, Gentoo on Android[3], we can run native Gentoo on *all* the Android devices. Compiling out an Xorg and output to HDMI has no theoretical difficulty. Furthermore, sharing of graphic output with Android (instead of a separate HDMI output) can be explored with wayland x11[4]. I feel sorry to the behavior of Canonical. We, people from the Gentoo community, can show the general public what is the cooperative way to develop desktop/smartphone hybrid to benefit all. I would like to kick out a sub-project of Gentoo targeting smartphone and tablets. It would be nice to find out a solution based on Gentoo for desktop/smartphone hybrid *before* Canonical's release. Comments welcome. Cheers, Benda 1. http://www.ubuntu.com/phone/ubuntu-for-android 2. http://www.indiegogo.com/projects/ubuntu-edge 3. http://www.awa.tohoku.ac.jp/~benda/projects/android.html 4. http://en.wikipedia.org/wiki/Wayland_%28display_server_protocol%29
[gentoo-dev] RFC: GLEP rap (Prefix/libc)
entation can found at developer `overlay of heroxbd`_. The native variant of sysroot feature of binutils and gcc discussed in this GLEP will be submitted upstream after thorough testing. References == .. _Gentoo on Android: http://www.awa.tohoku.ac.jp/~benda/projects/android.html .. _Gentoo Prefix: http://prefix.gentoo.org .. [#centos5] emerge gcc 4.4.x/4.5.x fails ..., http://thread.gmane.org/gmane.linux.gentoo.alt/6110 .. [#fortify] >=sys-devel/gcc-4.3 fails ..., https://bugs.gentoo.org/show_bug.cgi?id=289757 .. [#pgx86] Moving prefix/EAPI-3 support into the gentoo-x86 tree, https://bugs.gentoo.org/show_bug.cgi?id=315803 .. [#rpath] gcc/ld wrappers injecting correct flags stuff, http://article.gmane.org/gmane.linux.gentoo.alt/1125 .. [#glibcpfx] sys-libs/glibc Prefix support, https://bugs.gentoo.org/show_bug.cgi?id=473728 .. [#ldinfo] ld Info Section 3.4.2, Commands Dealing with Files .. _overlay of heroxbd: http://git.overlays.gentoo.org/gitweb/?p=dev/heroxbd.git .. _Android: http://www.android.com Copyright = This document has been placed in the public domain.
Re: [gentoo-dev] RFC: cartesian product extension to keyword system
Hi Ben, Ben de Groot writes: > To me this looks to be needlessly complex. There is an alternative way to do this: @-linux to mean "the ebuild works on every keyworded arch on Prefix with Linux kernel". Cheers, Benda
Re: [gentoo-dev] RFC: cartesian product extension to keyword system
Dearr Fabian, Fabian Groffen writes: >> Furthermore if the ebuild has "amd64" keyword, it will certainly >> build on amd64-linux too. > > Somewhat likely, but absolutely not true. Sorry, the original phrase was vague. I meant, if an ebuild is keyworded "amd64" and "x86-linux", it will certainly work on "amd64-linux" >> Therefore we propose the following cartesian product extension to >> keyword system. > > We added the keywords as is, to uniquely define which systems it works > on. Assuming something will work because it should be similar is (and > has been proven in the past to be) wrong. Every system is different. We are grouping similar systems into corresponding keywords, and already assuming ability for extrapolation. And now we observe that ARCH and KERNEL are quite independent. They can be decomposed into two dimensions. Why don't me exploit this fact? Cheers, Benda pgpftlilfsgwV.pgp Description: PGP signature
[gentoo-dev] RFC: cartesian product extension to keyword system
Dear all, In GLEP22[1], reasonable defaults has been introduced to prevent the explosion of keywords. With the growth of Gentoo Prefix, however, a substantial amount of keywords are introduced. Among them, duplex information exists. For example, an ebuild keyworded x86-linux(Gentoo Prefix on x86 linux) will certainly build on x86 (Gentoo vanilla on x86 linux). Furthermore if the ebuild has "amd64" keyword, it will certainly build on amd64-linux too. This duplication becomes more manifested during the development of Gentoo Prefix on arm. Introducing an arm-linux keyword is objected by developers because we are having too many keywords[2]. But it is far from consensus yet, as people are already adding arm-linux to ebuilds[2]. There were also a proposal to treat arm the same as arm-linux, but received more objections for its vagueness. Therefore we propose the following cartesian product extension to keyword system. a. introducing four more variables, in order, KEYWORDS_ARCH, KEYWORDS_KERNEL, KEYWORDS_USERLAND, KEYWORDS_LIBC. An order relation is defined as arch > kernel > userland > libc b. KEYWORDS_var1 must be defined if KEYWORDS_var2 is defined and var2 < var1. Otherwise it can be omitted. c. KEYWORDS_PROD is defined as cartesian product of KEYWORDS_ARCH, KEYWORDS_KERNEL, KEYWORDS_USERLAND, KEYWORDS_LIBC. Omitted variable is interpreted as empty and not counted in the product. e.g., if KEYWORDS_USERLAND and KEYWORDS_LIBC are not defined, KEYWORDS_PROD is the product of KEYWORDS_ARCH and KEYWORDS_KERNEL. c1. "~" is attached to KEYWORDS_PROD elements if any of its oprand has "~". d. KEYWORDS is redefined as union of KEYWORDS_PROD and KEYWORDS (for backward compatibility) e. reasonable defaults in GLEP22 applys. Therefore, for sys-devel/bison, the keywords proposed will be: KEYWORDS="~hppa-hpux ~m68k-mint ~ppc-aix ~x64-solaris ~x86-interix KEYWORDS_ARCH="~alpha ~amd64 ~arm ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86" KEYWORDS_KERNEL="~linux ~solaris ~freebsd ~fbsd ~macos" Problems remaining: a. how to do stablization in this case? b. how to handle things that does not exist? e.g. sparc-macosx? c. how to clean up confusions? e.g. x64-solaris vs amd64-solaris, freebsd (Gentoo Prefix on FreeBSD) vs fbsd (Gentoo/FreeBSD) Thanks, Benda 1. http://www.gentoo.org/proj/en/glep/glep-0022.html 2. see sys-devel/bison, ~alpha ~amd64 ~amd64-fbsd ~amd64-linux ~arm ~arm-linux ~hppa ~hppa-hpux ~ia64 ~ia64-hpux ~ia64-linux ~m68k ~m68k-mint ~mips ~ppc ~ppc-aix ~ppc-macos ~ppc64 ~s390 ~sh ~sparc ~sparc-fbsd ~sparc-solaris ~sparc64-solaris ~x64-freebsd ~x64-macos ~x64-solaris ~x86 ~x86-fbsd ~x86-freebsd ~x86-interix ~x86-linux ~x86-macos ~x86-solaris
Re: [gentoo-dev] Python 2.7.4, 3.2.4, 3.3.1 updates
Dear Mike, Mike Gilbert writes: > This seems like a good opportunity to add slot operator deps and > remove some prefix workarounds. We can keep an old ebuild around to > facilitate upgrades if we need to. What kind of prefix workaround are you referring to? This reminds me that Prefix team is maintaining aqua support (GUI for Mac OS X) in Python in their own overlay for a long time. I'd like to see it merged to gx86. If feasible, I am going to run out a patch for review. Cheers, Benda
Re: [gentoo-dev] net-p2p/deluge needs a maintainer
Hi, Markos Chandras writes: > net-p2p/deluge has open bugs for years[1] and I don't see anybody from > the net-p2p herd to actually maintain it. It would be nice to find a > new dedicated maintainer for it. I will take it as an active user myself. Added myself to net-p2p alias already. And I have nailed several bugs already ;) Cheers, Benda
[gentoo-dev] meaning of EROOT
Dear All,
I am a bit confused with the meaning of EROOT.
In a usual Prefix installation, ROOT=/ and EPREFIX=/opt/gentoo,
EROOT=/opt/gentoo/.
Naturally, EROOT=${EPREFIX}${ROOT}, right?
But for example in ./python.eclass
EROOT="${ROOT%/}${EPREFIX}/"
and in LocationsManager.py of portage
self.eroot = self.target_root.rstrip(os.sep) + self.eprefix + os.sep
What is the logic behind this construction?
The problem rises when I want to cross-compile under Prefix. Taking
armv7a-hardfloat-linux-gnueabi for example,
ROOT=/usr/armv7a-hardfloat-linux-gnueabi/, EPREFIX=/opt/gentoo. I'd
expect EROOT to be ${EPREFIX}${ROOT}, therefore,
/opt/gentoo/usr/armv7a-hardfloat-linux-gnueabi/. At present
EROOT=/usr/armv7a-hardfloat-linux-gnueabi/opt/gentoo/, which is
completely useless.
Cheers,
Benda
Re: [gentoo-dev] rfc: OpenRC network provides revisited
William Hubbs writes: > If you are running services that "need net" and you have turned off all > of the "net" providers by adding something like rc_provide="!net" to > their conf.d files, the services that need net will fail hard even > though they shouldn't. If we set rc_provide="net" in rc.conf, the services that need net can be tricked as we intended to. pgpV5Q8f4LBpF.pgp Description: PGP signature
Re: [gentoo-dev] rfc: OpenRC network provides revisited
Besides, IMHO, we should avoid changing OpenRC's default dependency too often. The solution for one user can be received as a regression to others. People file bugs saying "it worked for OpenRC-0.9 but not 0.10". For devs, we know we just changed default value of something perfectly configurable. But for that user, it is quite discouraging to feel "something in OpenRC is still unstable". pgphAELvIHeEE.pgp Description: PGP signature
Re: [gentoo-dev] rfc: OpenRC network provides revisited
Hi William, William Hubbs writes: > When network interfaces are pre-configured, our network scripts > shouldn't run at all, but they can be forced to run if other services > have "need net" in their dependencies. > > So my question is, should we change our services to "use net" instead of > "need net"? I don't think we should make this change. People have different setups. We cannot provide a default configuration that covers all corner cases. Instead, we can show the user how to customize openrc and change the default behavior. e.g. setting rc_provide="net" and rc_depend_strict="NO", works for this case. Our focus can be on providing more useful debug message to user, like when net.lo fails to stop openrc outputs who pulled it in and how to disable this behavior. Yours, Benda pgpuPQdhwP0C9.pgp Description: PGP signature
Re: [gentoo-dev] OpenRC and SystemD Config File Parity
"Jason A. Donenfeld" writes: > To what degree is there parity of configuration formats between OpenRC > and SystemD? Obviously there will never be any sort of parity ever for > Unit files, but what about for the general parameters of the system? > machine-id, locale, timezone, hostname, et cetera. In OpenRC they are mostly in /etc/conf.d. How about systemd? > I suppose when I refer to OpenRC, I'm really talking about Baselayout. > > I guess more specifically what I'm wondering is: > > - What is the current state of differences between config file formats > and locations used for OpenRC/Baselayout and SystemD? config file formats differs a lot, for OpenRC it's shell script, while for SystemD Microsoft ini/XDG Desktop Entry Specification. > - Is parity desirable? Are some people working on this? Thought of that before, but haven't gain much motivation yet. > - Are there advantages / disadvantages? Which files, for what, and > why? I'm not sure. > Anyway, if folks have opinions or thoughts, I'd love to hear them. But > this is just loose inquiry, not a pressing question for a project in > motion, so don't feel compelled to exsanguinate your soul here. Oh I'm scared ;)
Re: [gentoo-dev] pid 1 design
Michał Górny writes: > Considering that systemd unit files are sometimes shipped with upstream > packages, and often they are practically equivalent to openrc init > scripts, I'd rather see openrc supporting that file format > as an extension and using it instead of duplicating the same thing > in init.d scripts. I bet this resonate with many minds out here. I am also planning to make a draft implementation. > And yes, that means that people masking service files shoot themselves > in the foot. > > Also, if I had more time (or support), I'd probably start working > on a systemd-compatible init system with a more portable design. pgp74E5qQ6JNA.pgp Description: PGP signature
Re: [gentoo-dev] Last rites: app-text/epdfview
Hi, "Andreas K. Huettel" writes: > # Andreas K. Huettel (7 Aug 2012) > # Many display bugs and compatibility problems, does not build with cups-1.6. > # Upstream is dead. There's no real way to support this anymore. Masked for > # removal in 30 days. > app-text/epdfview I remember when xpdf was removed, epdfview was recommended as a lightweight alternative. How about this time? Best, Benda pgp20yldw1oEV.pgp Description: PGP signature
Re: [gentoo-dev] grub:2 keywords
Mike Gilbert writes: > My main concern is that many people probably have sys-boot/grub in > @world. How about a news item advising people to put sys-boot/grub:0 in their world file to retain grub:0? > If grub:2 is made visible, portage will install it, and will remove > grub-0.97 on the next depclean. This could be a little confusing, but > should not cause any immediate damage since the copy of grub-0.97 > installed in the MBR and /boot would remain intact. > > Is this worthy of a news item? Or I just blog about it? pgpGRtgZ6kn8y.pgp Description: PGP signature
Re: [gentoo-dev] new virtual/pkgconfig to support lighter alternatives
Hi Mike, Mike Frysinger writes: > the canonical pkg-config is getting fat. it requires glib-2. it runs > pkg- config when building. glib-2 requires pkg-config. whee. > any comments ? I would vote for it! I feel ill to bootstrap glib and pkg-config. It feels worse to call for a equal foot as gcc/binutils/glibc. http://article.gmane.org/gmane.comp.gnome.gtk%2B.devel.general/21523 pkg-config's functionality is too simple to be involved with this chaos. Looking forward to it. Yours, Benda pgpsP27uGxyU3.pgp Description: PGP signature
[gentoo-dev] RFC: ocamlopt unmask on arm
Dear All, I have just emerged ocaml-3.12.0[ocamlopt] on arm and used it to compile mldonkey[ocamlopt]. It seems to work well. it was masked on Apr 18, 2010, , | /usr/portage/profiles$ grep -n -B3 ocamlopt ./arch/arm/use.mask | 31-# Raúl Porcel | 32-# Fails to build/work | 33-openexr | 34:ocamlopt ` Debian has arm port for ocamlopt since 3.12: http://packages.debian.org/search?searchon=names&keywords=ocaml-native-compilers I failed to find the changelog of ocaml, though :( How about unmasking it now? Yours, Benda
