Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build
On poniedziałek, 30 stycznia 2017 14:04:06 CET William Hubbs wrote: > All, > > I have been looking at the meson build system [1] [2], and I like what I > see. > > I have opened an issue on OpenRC's github wrt migrating OpenRC to the > meson build system [3]. > > As I said on the bug, the downside is the addition of py3 and ninja as > build time dependencies, but I think the upside (a build system where > we don't have to worry about parallel make issues or portability) > outweighs that. > > What do folks think here? I'd recommend to jump a bandwagon and switch to CMake. Yes, it's ugly in certain areas, has its quirks but whoever switches to it ones, never goes back, and not because of technical debt being too big. Also because I can help with it (and a lot of folks can), while Meson is still largely unknown. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH 2/2] cmake-utils.eclass: export compilers to environment instead of setting in toolchain file, bug 542530
On piątek, 4 listopada 2016 20:58:23 CET James Le Cuirot wrote:
> On Fri, 4 Nov 2016 13:37:42 +0100
>
> Alexis Ballier <aball...@gentoo.org> wrote:
> > On Fri, 4 Nov 2016 12:33:37 +
> >
> > James Le Cuirot <ch...@gentoo.org> wrote:
> > > On Fri, 4 Nov 2016 13:20:16 +0100
> > >
> > > Alexis Ballier <aball...@gentoo.org> wrote:
> > > > On Thu, 3 Nov 2016 00:52:17 +0100
> > > >
> > > > Maciej Mrozowski <reave...@gmail.com> wrote:
> > > > > From: Maciej Mrozowski <reave...@gentoo.org>
> > > > >
> > > > > ---
> > > > >
> > > > > eclass/cmake-utils.eclass | 6 +++---
> > > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> > > > > index 88d2163..23cc094 100644
> > > > > --- a/eclass/cmake-utils.eclass
> > > > > +++ b/eclass/cmake-utils.eclass
> > > > > @@ -525,13 +525,13 @@ enable_cmake-utils_src_configure() {
> > > > >
> > > > > local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake
> > > > > cat > ${toolchain_file} <<- _EOF_ || die
> > > > >
> > > > > - SET (CMAKE_C_COMPILER $(tc-getCC))
> > > > > - SET (CMAKE_CXX_COMPILER $(tc-getCXX))
> > > > > - SET (CMAKE_Fortran_COMPILER $(tc-getFC))
> > > > >
> > > > > SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE
> > > > >
> > > > > FILEPATH
> > > >
> > > > Have you tested cross compiling ?
> > > > IIRC toolchain file is used *before* getting those vars from env and
> > > > is used to determine system & compiler type. Without this you get
> > > > bugs like #503216
> > >
> > > I was dubious (since I filed that bug) but I briefly tested by
> > > cross-compiling media-libs/openal and it worked. I didn't think to
> > > try older CMake versions though. The behaviour might have changed.
> >
> > could you please send me (in private) build logs with & without the
> > changes please ?
> >
> > (dont have easy access to a x compile setup atm)
>
> I diff'd the logs (needed MAKEOPTS="-j1") and they were practically
> identical, save for the expected change in configure arguments. I also
> tested with CMake 2.8 and that worked too. To further convince myself,
> I took the current eclass and loosely reversed the change we made for
> bug #503216. It failed with CMake 3.6 in exactly the same way it failed
> back then. I am therefore happy for this to proceed. Would you agree?
Env way w/ CMake is used (without toolchain file) where I work for a couple of
years with quite a bunch of exotic cross-compilers so I never doubted it would
work (with toolchain file lacking CMAKE__COMPILER variable).
The only thing surprised me here was CMake handling CC/CXX var multi-param
abuse acceptably.
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH 1/2] cmake-utils.eclass: CMake argument passing rework - clean build_rules and toolchain_file files from unrelated stuff (pass to CMake directly) - move some invariant CMake op
On czwartek, 3 listopada 2016 07:31:10 CET Michał Górny wrote:
> On Thu, 3 Nov 2016 00:52:16 +0100
>
> Maciej Mrozowski <reave...@gmail.com> wrote:
> > From: Maciej Mrozowski <reave...@gentoo.org>
> >
> > ---
> >
> > eclass/cmake-utils.eclass | 54
> > ++- 1 file changed, 21
> > insertions(+), 33 deletions(-)
> >
> > diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> > index 393ee28..88d2163 100644
> > --- a/eclass/cmake-utils.eclass
> > +++ b/eclass/cmake-utils.eclass
> > @@ -517,13 +517,10 @@ enable_cmake-utils_src_configure() {
> >
> > includes=""
> >
> > fi
> > cat > "${build_rules}" <<- _EOF_ || die
> >
> > - SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE FILEPATH "Archive
manager"
> > FORCE)>
> > SET (CMAKE_ASM_COMPILE_OBJECT " $
{includes}
> > ${CFLAGS} -o -c " CACHE STRING "ASM
compile
> > command" FORCE) SET (CMAKE_C_COMPILE_OBJECT "
> > ${includes} ${CPPFLAGS} -o -c
"
> > CACHE STRING "C compile command" FORCE) SET
(CMAKE_CXX_COMPILE_OBJECT
> > " ${includes} ${CPPFLAGS}
-o
> > -c " CACHE STRING "C++ compile command" FORCE)
SET
> > (CMAKE_Fortran_COMPILE_OBJECT "
> > ${includes} ${FCFLAGS} -o -c " CACHE
STRING
> > "Fortran compile command" FORCE)>
> > - SET (CMAKE_RANLIB $(type -P $(tc-getRANLIB)) CACHE FILEPATH
"Archive
> > index generator" FORCE) - SET (PKG_CONFIG_EXECUTABLE $(type -P
> > $(tc-getPKG_CONFIG)) CACHE FILEPATH "pkg-config executable" FORCE)>
> > _EOF_
> >
> > local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake
> >
> > @@ -531,6 +528,8 @@ enable_cmake-utils_src_configure() {
> >
> > SET (CMAKE_C_COMPILER $(tc-getCC))
> > SET (CMAKE_CXX_COMPILER $(tc-getCXX))
> > SET (CMAKE_Fortran_COMPILER $(tc-getFC))
> >
> > + SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE FILEPATH "Archive
manager"
> > FORCE) +SET (CMAKE_RANLIB $(type -P $(tc-getRANLIB)) CACHE
> > FILEPATH
> > "Archive index generator" FORCE)>
> > _EOF_
> >
> > if tc-is-cross-compiler; then
> >
> > @@ -571,32 +570,29 @@ enable_cmake-utils_src_configure() {
> >
> > # in Prefix we need rpath and must ensure cmake gets
> > our
default
> > linker path # right ... except for Darwin hosts
> > IF (NOT APPLE)
> >
> > - SET (CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE)
> > - SET (CMAKE_PLATFORM_REQUIRED_RUNTIME_PATH
> > "${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/${CHOST}/lib;${EPREFIX}/u
> > sr/$(get_libdir);${EPREFIX}/$(get_libdir)" -CACHE
> > STRING ""
FORCE)
> > -
> > + SET (CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE)
> > + SET (CMAKE_PLATFORM_REQUIRED_RUNTIME_PATH
> > "${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/${CHOST}/lib;${EPREFIX}/u
> > sr/$(get_libdir);${EPREFIX}/$(get_libdir)" CACHE STRING "" FORCE)>
> > ELSE ()
> >
> > -
> > - SET(CMAKE_PREFIX_PATH "${EPREFIX}${PREFIX}" CACHE
> > STRING ""
FORCE)
> > - SET(CMAKE_SKIP_BUILD_RPATH OFF CACHE BOOL "" FORCE)
> > - SET(CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE)
> > - SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE CACHE BOOL "")
> > - SET(CMAKE_INSTALL_RPATH
> > "${EPREFIX}${PREFIX}/lib;${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/$
> > {CHOST}/lib;${EPREFIX}/usr/$(get_libdir);${EPREFIX}/$(get_libdir)" CACHE
> > STRING "" FORCE) - SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH
TRUE CACHE
> > BOOL "" FORCE) -SET(CMAKE_INSTALL_NAME_DIR "${EPREFIX}$
{PREFIX}/lib"
> > CACHE STRING "" FORCE) -
> > + SET(CMAKE_PREFIX_PATH "${EPREFIX}${PREFIX}"
> > CACHE
STRING "" FORCE)
> > + SET(CMAKE_SKIP_BUIL
[gentoo-dev] [PATCH 2/2] cmake-utils.eclass: export compilers to environment instead of setting in toolchain file, bug 542530
From: Maciej Mrozowski <reave...@gentoo.org>
---
eclass/cmake-utils.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index 88d2163..23cc094 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -525,13 +525,13 @@ enable_cmake-utils_src_configure() {
local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake
cat > ${toolchain_file} <<- _EOF_ || die
- SET (CMAKE_C_COMPILER $(tc-getCC))
- SET (CMAKE_CXX_COMPILER $(tc-getCXX))
- SET (CMAKE_Fortran_COMPILER $(tc-getFC))
SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE FILEPATH "Archive
manager" FORCE)
SET (CMAKE_RANLIB $(type -P $(tc-getRANLIB)) CACHE FILEPATH
"Archive index generator" FORCE)
_EOF_
+ # Bug 542530, export those instead of setting paths in toolchain file
+ local -x CC=$(tc-getCC) CXX=$(tc-getCXX) FC=$(tc-getFC)
+
if tc-is-cross-compiler; then
local sysname
case "${KERNEL:-linux}" in
--
2.7.3
[gentoo-dev] [PATCH 1/2] cmake-utils.eclass: CMake argument passing rework - clean build_rules and toolchain_file files from unrelated stuff (pass to CMake directly) - move some invariant CMake option
From: Maciej Mrozowski <reave...@gentoo.org>
---
eclass/cmake-utils.eclass | 54 ++-
1 file changed, 21 insertions(+), 33 deletions(-)
diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index 393ee28..88d2163 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -517,13 +517,10 @@ enable_cmake-utils_src_configure() {
includes=""
fi
cat > "${build_rules}" <<- _EOF_ || die
- SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE FILEPATH "Archive
manager" FORCE)
SET (CMAKE_ASM_COMPILE_OBJECT "
${includes} ${CFLAGS} -o -c " CACHE STRING "ASM
compile command" FORCE)
SET (CMAKE_C_COMPILE_OBJECT "
${includes} ${CPPFLAGS} -o -c " CACHE STRING "C
compile command" FORCE)
SET (CMAKE_CXX_COMPILE_OBJECT "
${includes} ${CPPFLAGS} -o -c " CACHE STRING "C++
compile command" FORCE)
SET (CMAKE_Fortran_COMPILE_OBJECT "
${includes} ${FCFLAGS} -o -c " CACHE STRING
"Fortran compile command" FORCE)
- SET (CMAKE_RANLIB $(type -P $(tc-getRANLIB)) CACHE FILEPATH
"Archive index generator" FORCE)
- SET (PKG_CONFIG_EXECUTABLE $(type -P $(tc-getPKG_CONFIG)) CACHE
FILEPATH "pkg-config executable" FORCE)
_EOF_
local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake
@@ -531,6 +528,8 @@ enable_cmake-utils_src_configure() {
SET (CMAKE_C_COMPILER $(tc-getCC))
SET (CMAKE_CXX_COMPILER $(tc-getCXX))
SET (CMAKE_Fortran_COMPILER $(tc-getFC))
+ SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE FILEPATH "Archive
manager" FORCE)
+ SET (CMAKE_RANLIB $(type -P $(tc-getRANLIB)) CACHE FILEPATH
"Archive index generator" FORCE)
_EOF_
if tc-is-cross-compiler; then
@@ -571,32 +570,29 @@ enable_cmake-utils_src_configure() {
# in Prefix we need rpath and must ensure cmake gets
our default linker path
# right ... except for Darwin hosts
IF (NOT APPLE)
- SET (CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE)
- SET (CMAKE_PLATFORM_REQUIRED_RUNTIME_PATH
"${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/${CHOST}/lib;${EPREFIX}/usr/$(get_libdir);${EPREFIX}/$(get_libdir)"
- CACHE STRING "" FORCE)
-
+ SET (CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE)
+ SET (CMAKE_PLATFORM_REQUIRED_RUNTIME_PATH
"${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/${CHOST}/lib;${EPREFIX}/usr/$(get_libdir);${EPREFIX}/$(get_libdir)"
CACHE STRING "" FORCE)
ELSE ()
-
- SET(CMAKE_PREFIX_PATH "${EPREFIX}${PREFIX}" CACHE
STRING "" FORCE)
- SET(CMAKE_SKIP_BUILD_RPATH OFF CACHE BOOL "" FORCE)
- SET(CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE)
- SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE CACHE BOOL "")
- SET(CMAKE_INSTALL_RPATH
"${EPREFIX}${PREFIX}/lib;${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/${CHOST}/lib;${EPREFIX}/usr/$(get_libdir);${EPREFIX}/$(get_libdir)"
CACHE STRING "" FORCE)
- SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE CACHE BOOL
"" FORCE)
- SET(CMAKE_INSTALL_NAME_DIR "${EPREFIX}${PREFIX}/lib"
CACHE STRING "" FORCE)
-
+ SET(CMAKE_PREFIX_PATH "${EPREFIX}${PREFIX}"
CACHE STRING "" FORCE)
+ SET(CMAKE_SKIP_BUILD_RPATH OFF CACHE BOOL ""
FORCE)
+ SET(CMAKE_SKIP_RPATH OFF CACHE BOOL "" FORCE)
+ SET(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE CACHE
BOOL "")
+ SET(CMAKE_INSTALL_RPATH
"${EPREFIX}${PREFIX}/lib;${EPREFIX}/usr/${CHOST}/lib/gcc;${EPREFIX}/usr/${CHOST}/lib;${EPREFIX}/usr/$(get_libdir);${EPREFIX}/$(get_libdir)"
CACHE STRING "" FORCE)
+ SET(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE
CACHE BOOL "" FORCE)
+ SET(CMAKE_INSTALL_NAME_DIR
"${EPREFIX}${PREFIX}/lib" CACHE STRING "" FORCE)
ENDIF (NOT APPLE)
_EOF_
fi
# Common configure parameters (invariants)
- local common_config=${BUILD_DIR}/gentoo_common_config.cmake
local libdir=$(get_libdir)
- cat > "${common_config}" <<- _EOF
[gentoo-dev] [PATCH 0/2] cmake-utils small rework + bug 542530
From: Maciej Mrozowski <reave...@gentoo.org> Bummer, let me start it properly again, this time sending to reachable address. Maciej Mrozowski (2): cmake-utils.eclass: CMake argument passing rework - clean build_rules and toolchain_file files from unrelated stuff (pass to CMake directly) - move some invariant CMake options actually to invariants parts - eliminate common_config (pass to CMake directly) for better transparency cmake-utils.eclass: export compilers to environment instead of setting in toolchain file, bug 542530 eclass/cmake-utils.eclass | 60 +++ 1 file changed, 24 insertions(+), 36 deletions(-) -- 2.7.3
[gentoo-dev] Re: [PATCH 2/2] cmake-utils.eclass: export compilers to environment instead of setting in toolchain file, bug 542530
On środa, 2 listopada 2016 04:00:06 CET Maciej Mrozowski wrote:
> ---
> eclass/cmake-utils.eclass | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> index 88d2163..f7eac26 100644
> --- a/eclass/cmake-utils.eclass
> +++ b/eclass/cmake-utils.eclass
> @@ -525,13 +525,13 @@ enable_cmake-utils_src_configure() {
>
> local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake
> cat > ${toolchain_file} <<- _EOF_ || die
> - SET (CMAKE_C_COMPILER $(tc-getCC))
> - SET (CMAKE_CXX_COMPILER $(tc-getCXX))
> - SET (CMAKE_Fortran_COMPILER $(tc-getFC))
> SET (CMAKE_AR $(type -P $(tc-getAR)) CACHE FILEPATH "Archive
> manager" FORCE)
> SET (CMAKE_RANLIB $(type -P $(tc-getRANLIB)) CACHE FILEPATH
> "Archive
> index generator" FORCE)
> _EOF_
>
> + # Bug 542530, export those instead of setting paths in toolchain file
> + tc-export CC CXX FC
> +
> if tc-is-cross-compiler; then
> local sysname
> case "${KERNEL:-linux}" in
mgorny commented to use local instead:
local -x CC=$(tc-getCC)
...
If no other comments, I'll apply this and commit patches somewhere around next
weekend. Would be nice if someone using some exotic prefix tried this (should
work though, we feed various cross-compilers to cmake via env this way at
work).
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Enable CMAKE_WARN_UNUSED_CLI by default in cmake-utils for EAPI>=6
On Wednesday 18 of May 2016 09:22:53 Andrew Savchenko wrote:
> On Mon, 02 May 2016 18:06:44 +0200 Maciej Mrozowski wrote:
> > Hello,
> >
> > General advise: do not convert ebuilds inheriting cmake-utils to EAPI 6
> > unless you know what you are doing (you are fully aware of eclass
> > behaviour removed with https://bugs.gentoo.org/show_bug.cgi?id=514384).
> >
> > Background:
> >
> > Pre EAPI-6 cmake-utils.eclass contained certain feature to mitigate CMake
> > variable case changes done by upstream.
> > This feature was explicitly removed with
> > https://bugs.gentoo.org/show_bug.cgi?id=514384 and no alternative was
> > proposed.
> > It opened new area of possible ebuild regression bugs when switching to
> > EAPI-6 for ebuilds inheriting cmake-utils.eclass.
> >
> > Unfortunately there is common misconception, also among developers, that
> > it's sufficient to simply replace "${cmake-utils_use_with foo)" with
> > "-DWITH_foo=ON" etc.
> > This is MOST OF THE TIME not the case.
> > When converting cmake-utils ebuild to EAPI>=6, one needs to consult
> > CMakeLists.txt wrt case each variable is written with since CMake is case-
> > sensitive and WITH_FOO != WITH_foo != WITH_Foo.
> >
> > Proposal:
> >
> > CMake allows warning about unused CMake variables passed by CLI. Since
> > this is how Gentoo passes ebuild configuration options, it's proposed to
> > enable this feature.
> > Unfortunately it won't fail compilation but at least it gives a chance to
> > spot case mismatch when reading build output.
> >
> > Future thoughts:
> >
> > For better damage control it's technically possible to extend configure
> > phase of cmake-utuls eclass to check mycmakeargs against parsed package
> > buildsystem but this might not be very reliable.
>
> For me the real confusion was from this line:
>
> die "${FUNCNAME[1]} is banned in EAPI 6 and later: use
> -D$1${arg}=\"\$(usex $2)\" instead"
>
> It recommends to use ${arg} without any warning about case, so when I just
> copied what it recommends: -DWITH_nls="$(usex nls)", I had a nice surprise
> and fun debugging.
Ah, there you go..
@kensington
Come on, man, you should have known better.
Invalid suggestion removed. Thanks for noticing.
I prefer to have developers figure out the right EAPI-6 migration path
themselves rather than blindly relying on suggestions:
diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index 427c13f..5958230 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -161,7 +161,7 @@ _cmake_use_me_now() {
local arg=$2
[[ ! -z $3 ]] && arg=$3
- [[ ${EAPI} == [2345] ]] || die "${FUNCNAME[1]} is banned in EAPI 6 and
later: use -D$1${arg}=\"\$(usex $2)\" instead"
+ [[ ${EAPI} == [2345] ]] || die "${FUNCNAME[1]} is banned in EAPI 6 and
later"
local uper capitalised x
[[ -z $2 ]] && die "cmake-utils_use-$1 []"
@@ -184,7 +184,7 @@ _cmake_use_me_now_inverted() {
[[ ! -z $3 ]] && arg=$3
if [[ ${EAPI} != [2345] && "${FUNCNAME[1]}" != cmake-
utils_use_find_package ]] ; then
- die "${FUNCNAME[1]} is banned in EAPI 6 and later: use -
D$1${arg}=\"\$(usex $2)\" instead"
+ die "${FUNCNAME[1]} is banned in EAPI 6 and later"
fi
local uper capitalised x
regards
MM
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Re: [RFC] Enable CMAKE_WARN_UNUSED_CLI by default in cmake-utils for EAPI>=6
On Monday 02 of May 2016 18:13:38 you wrote:
> On Monday 02 of May 2016 18:06:44 you wrote:
> > Unfortunately there is common misconception, also among developers, that
> > it's sufficient to simply replace "${cmake-utils_use_with foo)" with
> > "-DWITH_foo=ON" etc.
>
> Obvious errata, should be:
> Unfortunately there is common misconception, also among developers, that
> it's sufficient to simply replace "${cmake-utils_use_with foo)" with "-
> DWITH_foo=$(usex foo)" etc.
And commited:
diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index ebcb631..427c13f 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -87,7 +87,6 @@ _CMAKE_UTILS_ECLASS=1
# Warn about variables that are declared on the command line
# but not used. Might give false-positives.
# "no" to disable (default) or anything else to enable.
-: ${CMAKE_WARN_UNUSED_CLI:=no}
# @ECLASS-VARIABLE: PREFIX
# @DESCRIPTION:
@@ -113,7 +112,8 @@ _CMAKE_UTILS_ECLASS=1
# Should be set by user in a per-package basis in /etc/portage/package.env.
case ${EAPI} in
- 2|3|4|5|6) : ;;
+ 2|3|4|5) : ${CMAKE_WARN_UNUSED_CLI:=no} ;;
+ 6) : ${CMAKE_WARN_UNUSED_CLI:=yes} ;;
*) die "EAPI=${EAPI:-0} is not supported" ;;
esac
regards
MM
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Re: [RFC] Enable CMAKE_WARN_UNUSED_CLI by default in cmake-utils for EAPI>=6
On Monday 02 of May 2016 18:06:44 you wrote:
> Unfortunately there is common misconception, also among developers, that
> it's sufficient to simply replace "${cmake-utils_use_with foo)" with
> "-DWITH_foo=ON" etc.
Obvious errata, should be:
Unfortunately there is common misconception, also among developers, that it's
sufficient to simply replace "${cmake-utils_use_with foo)" with "-
DWITH_foo=$(usex foo)" etc.
regards
MM
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] [RFC] Enable CMAKE_WARN_UNUSED_CLI by default in cmake-utils for EAPI>=6
Hello,
General advise: do not convert ebuilds inheriting cmake-utils to EAPI 6 unless
you know what you are doing (you are fully aware of eclass behaviour removed
with https://bugs.gentoo.org/show_bug.cgi?id=514384).
Background:
Pre EAPI-6 cmake-utils.eclass contained certain feature to mitigate CMake
variable case changes done by upstream.
This feature was explicitly removed with
https://bugs.gentoo.org/show_bug.cgi?id=514384 and no alternative was
proposed.
It opened new area of possible ebuild regression bugs when switching to EAPI-6
for ebuilds inheriting cmake-utils.eclass.
Unfortunately there is common misconception, also among developers, that it's
sufficient to simply replace "${cmake-utils_use_with foo)" with "-DWITH_foo=ON"
etc.
This is MOST OF THE TIME not the case.
When converting cmake-utils ebuild to EAPI>=6, one needs to consult
CMakeLists.txt wrt case each variable is written with since CMake is case-
sensitive and WITH_FOO != WITH_foo != WITH_Foo.
Proposal:
CMake allows warning about unused CMake variables passed by CLI. Since this is
how Gentoo passes ebuild configuration options, it's proposed to enable this
feature.
Unfortunately it won't fail compilation but at least it gives a chance to spot
case mismatch when reading build output.
Future thoughts:
For better damage control it's technically possible to extend configure phase
of cmake-utuls eclass to check mycmakeargs against parsed package buildsystem
but this might not be very reliable.
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Reminder: ALLARCHES
On Monday 02 of May 2016 16:43:01 you wrote: | On Saturday 30 of April 2016 23:16:42 Andreas K. Huettel wrote: | | Hi all, | | | | just as a small reminder, to ease the load on all arch teams: | | | | If a stablerequest has the keyword ALLARCHES set, then | | * the first arch that tests successfully and stabilizes | | * can and *should* immediately stabilize for all requested arches! | | | | Whether this keyword is set on a bug is decision of the package | | maintainer. | | | | For example, Perl team sets ALLARCHES normall for all pure-perl packages | | (i.e., no compilation / gcc involved). | | | | Here's an example how this was used: | | https://bugs.gentoo.org/show_bug.cgi?id=578408 | | https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=44c2d31dfc61bb3e2aee3 | | 70 9cb5a784b213511fa | | Going further, perhaps introducing something along the lines of 'noarch' to | KEYWORDS syntax would solve the problem in long run? | Or do we really need to have fine grained control over packages visibility | even for those that are really processor architecture agnostic? Yes, subject was discussed: http://article.gmane.org/gmane.linux.gentoo.devel/63776/match=noarch or http://article.gmane.org/gmane.linux.gentoo.devel/89824/match=noarch but I perhaps it's worth re-revisiting since it's hard to find definitive conclusion to those topics. regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Reminder: ALLARCHES
On Saturday 30 of April 2016 23:16:42 Andreas K. Huettel wrote: | Hi all, | | just as a small reminder, to ease the load on all arch teams: | | If a stablerequest has the keyword ALLARCHES set, then | * the first arch that tests successfully and stabilizes | * can and *should* immediately stabilize for all requested arches! | | Whether this keyword is set on a bug is decision of the package maintainer. | | For example, Perl team sets ALLARCHES normall for all pure-perl packages | (i.e., no compilation / gcc involved). | | Here's an example how this was used: | https://bugs.gentoo.org/show_bug.cgi?id=578408 | https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=44c2d31dfc61bb3e2aee370 | 9cb5a784b213511fa Going further, perhaps introducing something along the lines of 'noarch' to KEYWORDS syntax would solve the problem in long run? Or do we really need to have fine grained control over packages visibility even for those that are really processor architecture agnostic? regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFI: A better workflow for github pull requests
On Saturday 12 of September 2015 21:12:25 Michał Górny wrote: | What are your thoughts? Any other proposals? Well, there's always an option to set up infra hosted Gerrit or Gitlab and forget about Github workflow altogether... regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] useflag policies
On Sunday 02 of August 2015 21:37:36 Rich Freeman wrote: | The approach qt4=qt4 | and qt5=qt5 seems simpler on the surface, but it means that users end | up having to set tons of per-package configurations when they don't | actually care which one they use, I will risk a thesis that if they didn't care, they wouldn't have chosen Gentoo... regards MM
[gentoo-dev] Re: Herd/project cleanup
On Saturday 27 of June 2015 21:39:35 Johannes Huber wrote: Feel free to keep me there. (although my usefulness has lessened of late...) regards MM
[gentoo-dev] Last rites: sys-fs/evms
# Maciej Mrozowski reave...@gentoo.org (06 Apr 2015) # Does not link against latest ncurses and no interest to fix it. # Superseded by LVM2 and all clusters should be migrated by now. # Removal in 30 days. sys-fs/evms I kept it in tree for a while longer for volumes migration purpose, but all good things must come to an end eventually. regards MM
Re: [gentoo-dev] RFC GLEP 1005: Package Tags
On Monday 24 of March 2014 16:28:44 Ciaran McCreesh wrote: | On Mon, 24 Mar 2014 10:55:38 -0400 | Damien Levac damien.le...@gmail.com wrote: | A lot of people already replied to this question: package search. | | Sure, but can you point to prior examples of this kind of stuff | actually working? https://wiki.debian.org/Debtags http://debtags.debian.net/search/ True, may not be as popular as full-text description search. regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] crossdev and multilib interference
On Wednesday 26 of March 2014 02:07:56 Mike Frysinger wrote: | cmake is completely broken when it comes to library searching and multilib and | cross-compiling. it will happily look in hardcoded / paths to test for the | existence of files as well as directly execute `pkg-config`. it's a great | example of people saying autotools is crap, so let's invent our own kind of | crap and ignore lessons learned. this isn't the fault of cmake eclasses, but | it'd be nice if we could someone standardize the hacks in there so we don't | have to duplicate across ebuilds. If we provided toolchain.cmake (passed to CMake via -DCMAKE_TOOLCHAIN_FILE=path) file for each crossdev, that could not only set compiler paths/etc but also override CMAKE_SYSTEM_PREFIX_PATH, we would get pretty close to autotools. Yes, CMake has pretty rudimentary (to put it mildly..) cross-compilation support but it still can be done there somewhat right. regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Friday 17 of January 2014 13:06:22 gro...@gentoo.org wrote: | dev-util/kdevelop-php-docs While of course it doesn't invalidate your entire idea, this particular example is a kdevelop plugin written in C++ that provides php API documentation integration. This tells however that decision to auto-keyword/stabilize remaining arches cannot be taken lightly and not by everyone. regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Recommend cronie instead of vixie-cron in handbook?
On Sunday 15 of December 2013 00:13:09 Peter Stuge wrote: | Markos Chandras wrote: | Please do not let Peter render another thread useless. | | Isn't it obvious that the discussion about forks is both related to | cron *and* useful on its own? I think there's some misunderstanding (or otherwise trolling). There's no discussion as there are no competing forks. There is discontinued (judged by upstream and bug activity) project and there is follow-up project. | It's not really possible to view an entire thread as a single item. | Life is more complicated than that, for good and bad. | | Finally, consider that even if what I write makes you personally | uncomfortable it may still be useful for the community as a whole. In this particular thread, lecturing us on forks (in ex. not always being automatically profitable), while at the same time likely being unaware of status of vixie-cron development and its Gentoo maintenance story, then trying to get what we define as 'dead upstream' in pretentious one-liners like someone's life depended on it is what Markos called it - useless - not 'personally uncomfortable'. | You can only decide what is useless for you - and I don't care even | if you think that I'm useless for Gentoo (I didn't say that you've | said so, I am only saying if!) but I do care if you claim that your | opinion is representative of the entire community, as you did above. | That's not cool. Neither is trolling. Please be so kind and discontinue this practice. Thanks for understanding. regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] open season on other-dev's packages -- policy change?
On Friday 01 of November 2013 22:13:04 Ciaran McCreesh wrote: | The point is that git makes it super-easy to contribute patches, both | for users and for developers. Well, it's not like one cannot submit patches against portage tree patches already.. And git is only super-convenient when combined with proper review tool, preferably with 'auto-push'. But then again who would honestly 'trust' user-submitted merge request without trying to 'QA'* the package himself? The 'need' to check it myself delays user submissions in my case anyway. (moving to git would likely help with shortening the cycle when combined with having 'overlays' being git clones of official gentoo-x86. I'm afraid however whole 'atomic' tree is just too huge to be practically cloned. Maybe Exherbo-like concept of project-specific git repos would work but splitting gentoo-x86 would sounds like a revolution) * - looking for possible automagic in buildsystem, checking installed filelist regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Sets in the tree
On Wednesday 14 of August 2013 21:42:35 Michael Palimaka wrote:
| Now that portage-2.2 is in ~arch, we should now be able to add sets to
| the tree.
|
| How should we go about doing this? In some overlays, the repository root
| has sets/{foo,bar,etc} and sets.conf which might look like this:
|
| [gentoo sets]
| class = portage.sets.files.StaticFileSet
| multiset = true
| directory = ${repository:gentoo}/sets/
| world-candidate = True
|
| It might be useful to have a standard header for each set:
|
| # Maintainer: f...@example.com
| # Description: The complete set of all Foo packages
|
| Should everyone be free to add sets at will, or should each addition be
| discussed first, similar to adding new global USE flags?
|
| Anything else to consider?
Discussion about current portage sets was sure to get hot.
I strongly disagree with adding current portage sets to gentoo-x86.
Not because they're not PMS compliant (which is a reason alone) but because
they can be
considered interim solution.
Please refer to Zac's email on why portage-2.2_ was kept masked for that long.
For live rebuilds, there's already proposal:
https://bugs.gentoo.org/show_bug.cgi?id=272488
For proper 'metapackage' replacement (USE flags support, etc), actually there's
also some
idea (Zac's 'PROPERTIES=set'):
https://bugs.gentoo.org/show_bug.cgi?id=182028
In my opinion, we need to _have_ proper sets before we include them in
gentoo-x86.
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Evaluating a new malloc()
On Tuesday 26 of February 2013 11:44:31 Rich Freeman wrote: On Tue, Feb 26, 2013 at 11:35 AM, Alec Warner anta...@gentoo.org wrote: I see a *HUGE* reason. glibc ships with ptmalloc. If you think they should use jemalloc, talk to them. Don't just do it in Gentoo. Certainly I think it would be far more productive to talk to the glibc maintainers first. You mean productive like below? ;) http://sourceware.org/bugzilla/show_bug.cgi?id=11261 Ulrich Drepper: Stop reopening. There is a solution for people who are stupid enough to create too many threads. No implementation will be perfect for everyone. The glibc implementation is tuned for reasonable programs and will run much faster than any other I tested. Merge of jemalloc upstream is likely never going to happen. regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
On Thursday 07 of February 2013 06:52:44 Peter Stuge wrote: Tomáš Chvátal wrote: we as gentoo will provide both while preffered default will be what major distros use. What kind of careless mainstream attitude is that? Really? Quite the opposite, decision to use implementation A over B was taken with utmost care for user in mind. I mean: You are saying that given two options, Gentoo will do whatever major distros are doing. (Never mind that Gentoo *is* a major distro, and whatever Gentoo does generates collective bias just like whatever any other distro does.) We are not, let's not go too far, please. Oops, I forgot - that would mean actually having to *get informed* first. We as gentoo must certainly avoid getting informed at all cost111oneone Are you *really* quite serious? Please explain yourself. If you disagree with that and you don't want your lead to make that decision Hm? Where can I learn more about the lead ? So it is a single person's decision, and not we as gentoo that decides? I'd like to understand how this decision making process actually works. Does anyone know? It depends - in distro-wide, package-tree-wide matters we have Gentoo Council. In local matters like this - who does the job decides. Tomáš does the job - he decides. which you and I both don't want. Guess what - I have been on the receiving end of the arguably insanely lame mainstream attitude that you support, and honestly it fucking broke my heart that people working on Linux distributions (it wasn't just Gentoo, it was *every* distro) would be so genuinely uninterested in what happens upstream, especially at a time where a downstream decision may carry a bit of extra weight. I do not want that. (Around the time this happened to me I wrote roughly the same in a private email to developers of another distribution which shall remain unnamed. I found that email in a pastebin a few days later.) It is long since clear to me that I have much too high expectations on people. But are you *REALLY* not able to do *any* better than default will be what major distros use ? Seriously? Seriously you should take a deep breath, walk a dog maybe :) regards MM signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [PATCH 3/3] Convert virtualgl to cmake-multilib.
On Tuesday 05 of February 2013 21:19:24 you wrote:
+CMAKE_VERBOSE=1
This is already eclass default.
+ abi_configure() {
+ local mycmakeargs=(
+ ${mycmakeargs[@]}
+ -DVGL_LIBDIR=/usr/$(get_libdir)
+ -DTJPEG_LIBRARY=/usr/$(get_libdir)/libturbojpeg.so
+ -DCMAKE_LIBRARY_PATH=/usr/$(get_libdir)
+ -DVGL_FAKELIBDIR=/usr/fakelib/${ABI}
No no, we should patch CMake instead to avoid doing things like those for
every single ebuild. So to teach CMake to know our libsuffix and such.
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] The gx86 multilib project -- masterplan
On Sunday 27 of January 2013 19:11:16 Micha³ Górny wrote:
On Sun, 27 Jan 2013 21:04:14 +0300
Sergei Trofimovich sly...@gentoo.org wrote:
On Sun, 27 Jan 2013 17:30:22 +0100
Micha³ Górny mgo...@gentoo.org wrote:
On Sun, 27 Jan 2013 16:07:48 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Sun, 27 Jan 2013 16:12:37 +0100
Micha³ Górny mgo...@gentoo.org wrote:
RDEPEND=dev-libs/libfoo[${MULTILIB_USEDEP}]
dev-libs/libbar[ssl,${MULTILIB_USEDEP}]
This looks like it might be a bit fragile. Is it something better
addressed by an EAPI extension?
I have no idea. This one's clear and simple. Not sure how you could be
able to do that better in EAPI.
EAPI might allow lib[multiple?][use?][flags?] as an alias of
[multiple?,use?,flags?].
I still don't think that would be really helpful.
dev-libs/libfoo[ssl][${MULTILIB_USEDEP}]
is IMO just more confusing than the usual [ssl,...] -- people start
thinking 'does it mean something special?'
Unless you mean adding the brackets to the variable itself -- but that
will be just scary...
dev-libs/libfoo${MULTILIB_USEDEP}
Alternatively, less fragile but more verbose would be eclass function to
produce dependency string. While it may sound as overkill - we already do it
in KDE:
'add_kdebase_dep':
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/kde4-
functions.eclass?view=markup
Example usage:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/kde-
base/pykde4/pykde4-4.9.5.ebuild?view=markup
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] supporting static-libs
On Thursday 06 of September 2012 10:18:34 Brian Harring wrote:
On Mon, Sep 03, 2012 at 10:54:15PM +0200, Maciej Mrozowski wrote:
On Tuesday 28 of August 2012 02:15:40 hasufell wrote:
Is there a reason not to support static-libs in an ebuild if the
package supports it?
It seems some developers don't care about this option. What's the
gentoo policy on this? Isn't this actually a bug?
A little remark.
For CMake controlled buildsystem (as you're coming here from latest dev-
games/simgear), there's no automatic way of building both static and
shared libs (simgear allows to choose just one).
This is why I removed static libs support that you proposed for dev-
games/simgear (similar to ruby eclass abi handling - manually calling
phases twice to build package 1st as shared, 2nd time as static).
This is what I called not worth the effort in private discussion with
you, not quite I don't care for static libs :)
Guessing in the worst case, you can do a double compile to get around
this, no? And yes, that's freaking horrible, just verifying cmake
isn't doing something special that blocks it.
Not sure why they would need to block it, one build dir for static, second one
for shared. All safely separated (still stinks as a hack).
Is upstream doing anything about this, or is it not on their
radar/list-of-things-they-care-about ?
Off the radar.
CMake provides equivalent of '--enable-static --disable-shared' and '--
disable-static --enable-shared' by the means of BUIlLD_SHARED_LIBS and not
specifying linkage when defining library:
add_library(foo src1 src2)
It doesn't automatically provide both at the same time however. CMake is
cross-platform (meaning it support different generators: GNU Make, NMake,
Visual Studio Project, XCode etc) so their main audience aren't distros,
also on Windows for instance when shared .dll is created, also import .lib is
created. If static .lib was to be created as well, they would need to have
separate build subdir for it (and a bit more complex library resolution
algorithm).
Still, if developer bothers enough to provide them both, he can easily
implement it in buildsystem with explicitly given linkage (and separate target
names):
set(foo_SRC src1 src2)
add_library(foo SHARED ${foo_SRC})
if (ENABLE_STATIC)
add_library(foo_static STATIC ${foo_SRC})
endif ()
That being said I can understand why it's off the radar - technically
everything is already available, likely not worth the effort and in many cases
building both static/shared is actually not needed.
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] supporting static-libs
On Tuesday 28 of August 2012 02:15:40 hasufell wrote: Is there a reason not to support static-libs in an ebuild if the package supports it? It seems some developers don't care about this option. What's the gentoo policy on this? Isn't this actually a bug? A little remark. For CMake controlled buildsystem (as you're coming here from latest dev- games/simgear), there's no automatic way of building both static and shared libs (simgear allows to choose just one). This is why I removed static libs support that you proposed for dev- games/simgear (similar to ruby eclass abi handling - manually calling phases twice to build package 1st as shared, 2nd time as static). This is what I called not worth the effort in private discussion with you, not quite I don't care for static libs :) -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] skel.ebuild cosmetics (move RESTRICT after DEPEND)
On Monday 07 of May 2012 10:32:45 Samuli Suominen wrote: On 05/07/2012 02:24 AM, Ulrich Mueller wrote: Therefore I suggest we move this example a bit down in skel.ebuild as it's more logical to continue with new lines instead of applying in-between Any objections? Yes. Please leave it as it is. Yeah, I will if someone has a (good) argument for doing so. RESTRICT and PROPERTIES are on a single line and it's natural to add them to the second group of such variables, namely LICENSE, SLOT, KEYWORDS, and IUSE. Whereas DEPEND and RDEPEND typically extend over several lines; sometimes they are quite long. So, a RESTRICT line placed after *DEPEND will be much more easily missed than in its current place. And I use quite different 'rule' where to place variables: - to separate frequently changed ones (KEYWORDS, IUSE) with rather invariant ones (SLOT, LICENSE) Rationale: It generates smaller diffs (and less conflicts when doing semi-automatic merges of ebuild changes between branches as those are likely both IUSE and KEYWORDS changes, KEYWORDS changes are rarely desired to be included in merge, if IUSE is just below the line with KEYWORDS, KEYWORD change will be accidentally taken in) -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Deprecate EAPI1?
On Monday 12 of March 2012 01:49:35 Brian Harring wrote: On Sun, Mar 11, 2012 at 04:14:33PM +0100, Ch??-Thanh Christopher Nguy???n wrote: Ciaran McCreesh schrieb: Is there really much of a benefit to this? I guess for anybody who runs scripts to mass-manipulate ebuilds it might be helpful, but I think all the package managers planned on supporting all the EAPIs for quite a while longer. We have to support them indefinitely. It's not possible to uninstall a package whose EAPI is unknown. Would it be feasible to do a pkg_pretend() check and refuse install/upgrade if packages with unsupported EAPI are detected? The question should be is it worth doing it, rather than can we hack out something. As Ciaran said, PM's are going to be supporting EAPI1 indefinitely In principle, it's actually entirely possible for any PM to start supporting exclusively completely API and ABI-breaking EAPI. There's always the problem with self-upgrading software as it needs to somehow predict (and limit) its development to keep upgrade paths. We have this exact problem where I work (with updating basestation SW) and some solution for this software is to stop being self-upgrading. With external upgrade tool (which would rsync package tree do any vdb/metadata-magic needed) one could replace current PM with latest, API/ABI- incompatible PM version. Now, it may not really make sense for PM as upgrade process of PM itself isn't any different from upgrade process of any other package, still it would allow any API/ABI-breaking ebuild format changes to be introduced if we really need them so badly. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] crossdrev mingw 64 bit
On Tuesday 10 of January 2012 03:34:06 Dmitrij K wrote: Dear developers of crossdev. Can you realize --target mingw64 (for creating windows app 64 bit) (like mingw-w64.sourceforge.net)? And can you to add choising of building compilation: dynamic OR static linking to GCC library, for LGPL license of GCC using (mingw32.dll etc)? Hello, It is already there: crossdev --target x86_64-w64-mingw32 -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: deprecate /usr/share/doc/$PF
On Wednesday 21 of December 2011 04:40:09 Mike Frysinger wrote: On Tuesday 20 December 2011 20:44:03 Maciej Mrozowski wrote: I still think we should even make PN an unique identifier in order to be able to purge categories... that's different story though... a world without categories is a *lot* worse than a world with $PN free collisions Yeah.. because? Users of other distros seem to disagree with you however. (no other package manager I know relies on fixed package categories and uses tags to describe package purpose and PN-PV to identify it). But like I said, that's different story, let's not hijack this topic. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: deprecate /usr/share/doc/$PF
On Monday 19 of December 2011 02:52:54 Alexandre Rostovtsev wrote:
On Mon, 2011-12-19 at 01:08 +0100, Ulrich Mueller wrote:
[Why are there different Reply-To: headers in -dev and in -pms MLs?
Following up to both lists.]
I apologize for the mess; I had intended to bring the question up before
a wider audience, but failed to think through the consequences of two
mailing lists ending up in the reply-to.
For the sake of keeping discussion in one thread, I ask that further
replies should be made to gentoo-dev, not gentoo-pms.
How do you handle FEATURES=nodoc if you spread the documentation all
over the filesystem? Should Portage learn about all the special cases?
IMHO it would make more sense to leave the documentation under
/usr/share/doc and either configure the documentation viewer to find
it there, or (if that's not possible) create symlinks.
It's not all over the filesystem; in practice, the number of locations
I believe is fairly small (/usr/share/gtk-doc and /usr/lib/monodoc for
API documentation, and /usr/share/help, /usr/share/omf,
and /usr/share/doc/HTML for end-user help files are the only ones that I
know of), and adding them to portage's nodoc list seems much easier than
editing hundreds of ebuilds that already install docs there.
Documentation in Gentoo-specific /usr/share/doc subdirectories would not
be able to link to documentation pages in other packages without
fragile, hard-to-maintain scripts - and even with the best scripts,
things would break on package renames. Symlinks could work, but (if the
nodoc situation is resolved) would give package maintainers extra work
for no real benefit.
Can we please avoid the bloat of another directory level here?
${CATEGORY}/${PN} will be even longer than ${PF} in most cases.
The problem is that ($PN, $CATEGORY) pairs are not unique.
I still think we should even make PN an unique identifier in order to be able
to purge categories... that's different story though...
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] rewritten epatch
On Friday 18 of December 2009 20:07:47 Mike Frysinger wrote:
if (patch -p${count} ${EPATCH_OPTS} --dry-run -f
${PATCH_TARGET})
${STDERR_TARGET} 21 ; then
Just FYI.
There seems to be a little 'problem' with this, as patch is validated in --
dry-run mode before applying, no .rej files are generated, thus the only
feedback is hunk # that failed from ${T}/${patchfile}.out.
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] enable verbose build whenever it's possible
On Saturday 05 of November 2011 09:58:00 Kacper Kowalik wrote: Hi, I'd like to ask that we enable verbose building by default. I have cmake-utils.eclass in mind, because it's dead easy there, but there's a lot of packages that support things like make V=1 or make VERBOSE=1 too. I've seen too many bugs reports today that gave me cute, colorful build.logs and almost no information about underlaying bug... That's usually because users sometimes attach only relevant parts of build log (well, relevant according to their taste = last lines, even when they use parallel compilation). Any particular example of bug report with entire build log from cmake-utils in fancy mode, and still being unable to locate the problem? I ask, because we're appending summary just after configure phase to make vorbose logging of whole build process unecessary. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Implicit system dependencies
On Tuesday 23 of August 2011 18:54:04 Paweł Hajdan, Jr. wrote: On 8/22/11 12:21 PM, Michael wrote: I wrote a script to search for discrepancies between linked libraries and what's defined in (R)DEPEND, with the intention of improving QA for minimal package installs. It would be great to integrate this into portage and make it a part of the developer profile. This would just help prevent future breakages. It seems there are a couple of such home-grown solutions already. dberkholz used to have on in his dev webspace[1], we have one[2] in kde overlay... 1. http://dev.gentoo.org/~dberkholz/scripts/ (linking_libs, included_headers) 2. http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=tree;f=Documentation/maintainers;hb=master (dynlink_scanner + try_dlopen.c) -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] USE=introspection has been unmasked in the tree
On Tuesday 16 of August 2011 22:14:28 Nirbheek Chauhan wrote: 2011/8/17 Chí-Thanh Christopher Nguyễn chith...@gentoo.org: Nirbheek Chauhan schrieb: A side-note that we've wanted to get out to all devs is that everyone should *always* use IUSE=+introspection. Then why is it a flag? So that people who use, say, json-glib in embedded environments don't need to pull in a package that is quite unnecessary for them. Then why don't you make it a default flag in desktop/gnome profile instead? That way, the embedded users who don't use a desktop profile won't even need to take action to disable the flag. We didn't do that because the use-case for not enabling introspection is a marginal one. Ah, use case like KDE, we get it, Nirbheek :D As soon as it can be globally disabled (with a loss of functionality and packages availability) I won't complain. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: virtual/icon-theme
On Tuesday 02 of August 2011 20:32:32 Samuli Suominen wrote: On 08/02/2011 09:20 PM, Markos Chandras wrote: Hello fellow developers, I would like to discuss the possibility to create a new virtual package for all the icon-theme packages. According to this bug[1], it seems like pcmanfm, and possible other applications too, require an icon-theme to be present, no matter which one. So I think it would make sense to create a new virtual package to include all the existing icon-themes. ++: Avoid ugly dependencies like || ( x11-themes/foo-icon-theme x11-themes/bar-icon-theme ... ) --: Not all packages include the same icons so users may end up with missing icons for some applications. However, most icon themes should include all the basic icons. [1] https://bugs.gentoo.org/show_bug.cgi?id=376309 Thoughts? since whatever gets added to the virtual should be at least almost up to date with the spec, and provide the most common icons virtual/freedesktop-icon-theme for name, just my opinion... http://standards.freedesktop.org/ as HOMEPAGE freedesktop-b...@gentoo.org as maintainer ++ virtual/freedesktop-icon-theme is a better name IMHO as it's what this virtual icon theme actually is - theme compliant with freedesktop standard (so that can be used by applications claiming support like chromium, KDE, Gtk apps), not just some icon theme (as any instant messenger icon set would fall under some icon theme category for instance). -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Are tags just sets?
On Tuesday 28 of June 2011 05:26:29 Brian Harring wrote: On Sun, Jun 26, 2011 at 08:02:57AM +0100, Ciaran McCreesh wrote: Here's a completely different way of doing tags: First, standardise sets. We probably want to go with a format along the lines of: eapi = 4 description = Monkeys dev-monkey/howler dev-monkey/spider =dev-monkey/spanky-2.0 dev-monkey/squirrel where eapi has to be on the first line. Second, make a bunch of sets named kde-tag, editors-tag, xml-tag, monkeys-tag etc. This is a bit inverted- tagging is fundamentally pkg specific. If we did as you proposed and I wanted to find out all tags/descriptions for a pkg, the PM would have to scan every tags file there. Additionally, as others have indicated, it sucks have this data tucked away in another chunk of the tree, away from where the package data actually is (in cat/pkg/*). Advantages: dead easy to implement, backwards compatible, we need sets anyway. Disadvantages: doesn't use some horribly convoluted system of XML, wikis and web 2.0. Counter proposal; use what you're proposing as a cache. metadata.xml is the proper place for this- we store use.local data there for example, and cache the results of it in profiles/use.local.desc. Via this vcs concerns are addressed, data locality is preserved, and multiple modes of lookup are sanely supported. Roughly, and this is definitely a rough sketch: tags atom val=dev-util/diffballtag1 tag2 tag2 tag3/atom atom val==dev-util/diffball-1.0awesomeness/atom /tags From there, jammed into profiles, a master description list in 'tag: description' style format. Identifying the eapi is easy enough- just inspect the atom's that wind up in the tags list. Easy enough. Either way... thing everyone admits the current tree format has it's flaws; strikes me it's better to fit to the standards/conventions of the repo format as it is now. proceed w/ xml bashing ~harring Of course, nobody said metadata.xml would be the place that's to be immediately accessed by search tools. But as a data definition is concerned, metadata.xml is the right place for tags, not some obscure 'package.mask'- style flat file. Whether this information is to be processed for easier usage - by generating flat file with cat/pkg tag1 tag2 ... in each line for instance - is different story and nice to have probably. @Ciaran profiles/package.mask is quite convenient being flat file (although package.mask.d seems nicer, different story) as masking/unmasking groups of packages (KDE releases come to my mind) is a common use case. Sure, it would benefit from auto-updating (pkgmove mostly as package.mask editing is otherwise closely tied to package removals anyway). -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Are tags just sets?
On Monday 27 of June 2011 07:49:24 Ciaran McCreesh wrote: On Sun, 26 Jun 2011 17:12:27 +0200 Maciej Mrozowski reave...@gmail.com wrote: On Sunday 26 of June 2011 09:02:57 Ciaran McCreesh wrote: Here's a completely different way of doing tags: As far as sets are concerned, how about PROPERTIES=set? https://bugs.gentoo.org/show_bug.cgi?id=272488 It's been proposed years ago. Is there a need to reinvent sets format every time it's bought up? The problems with PROPERTIES=set remain exactly the same as they were when it was first proposed. Which is? No, been there, done that, won't work is not sufficient. Please elaborate. I see major disadvantage with this approach. It's painful to maintain. Imagine hundreds of different tags, with each package having at least two tags. You certainly don't expect anyone to be able to maintain that. Uh, I don't see how that's in any way difficult to maintain. No, it's not difficult, it's pain in ass to keep a hundred files with a few thousands lines each up2date with tree changes (pkgmove, cvs remove). Yes, it could be automated by some crafty cvs hook on server. However cvs hooks should be the last resort and not a tool to deal with consequences of broken design. Tag is a property or attribute of package That one's highly debatable. It's not debatable for those familiar with object oriented design concept. It may be debatable for database designers what's the best way to implement many to many association because they have means to auto-update referenced keys - we don't have those means so proposal to move tags to separate table isn't practical. PROPERTIES=set have the same advantages - they can also be pulled within dependency tree by other packages. Yes, but PROPERTIES=set has all of the problems it had when it was first proposed, and is the wrong way to implement sets. Disadvantages: doesn't use some horribly convoluted system of XML, wikis and web 2.0. Using already proven technologies and tools is barely disadvantage. I think last thing we need is yet another obscure format nothing widely usable understands. Good, so you'll be happy going with what Unix has been using for decades then. Indeed, with sets in bash (ebuild) format. Sets concept is completely orthogonal to tags concept, please do not mix unrelated things. Depends upon what you think the tags concept is. We've already established that everyone has a different idea of what tags are anyway. I don't know what's everyone's idea behind the tag, I refer to: http://en.wikipedia.org/wiki/Tag_(metadata) -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Are tags just sets?
Hello, On Sunday 26 of June 2011 09:02:57 Ciaran McCreesh wrote: Here's a completely different way of doing tags: As far as sets are concerned, how about PROPERTIES=set? https://bugs.gentoo.org/show_bug.cgi?id=272488 It's been proposed years ago. Is there a need to reinvent sets format every time it's bought up? First, standardise sets. We probably want to go with a format along the lines of: eapi = 4 description = Monkeys dev-monkey/howler dev-monkey/spider =dev-monkey/spanky-2.0 dev-monkey/squirrel where eapi has to be on the first line. Second, make a bunch of sets named kde-tag, editors-tag, xml-tag, monkeys-tag etc. I see major disadvantage with this approach. It's painful to maintain. Imagine hundreds of different tags, with each package having at least two tags. You certainly don't expect anyone to be able to maintain that. Also those files cannot be generated since there needs to be some original source of tags information to generate such 'sets' from. I don't need to remind one needs to keep those files synchronized with tree changes (package renames, removals) while tags in metadata.xml automatically ravel with package. Tag is a property or attribute of package and should be implemented as additional package information, metadata.xml is the most natural choice. Third, make tools that allow browsing, searching etc able to list things by tag (or sets in general). Advantages: dead easy to implement, backwards compatible, we need sets anyway. PROPERTIES=set have the same advantages - they can also be pulled within dependency tree by other packages. Disadvantages: doesn't use some horribly convoluted system of XML, wikis and web 2.0. Using already proven technologies and tools is barely disadvantage. I think last thing we need is yet another obscure format nothing widely usable understands. Sets concept is completely orthogonal to tags concept, please do not mix unrelated things. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] SHA256 and indention in metadata.xml
On Saturday 25 of June 2011 22:32:43 Jorge Manuel B. S. Vicetto wrote: On 25-06-2011 14:23, Nirbheek Chauhan wrote: On Sat, Jun 25, 2011 at 6:16 PM, justin j...@gentoo.org wrote: Another question, do we have a rule, how the metadata.xml has to be indented? Tabs or n spaces? There's no rule, but we should follow the same rule as ebuilds — indentation should be with a tab that's displayed as 4 spaces in editors (no expansion of tabs to spaces). Talking from my own experience when doing retirement stuff, there seems to be two large currents on metadata.xml in the tree, using tabs and 2 spaces for indentation. I personally prefer tabs, but I also like using EAPI=version, sorting everything alphabetically and even use the following depend blocks: *DEPEND= !X-2.0 !Y A B ... Z a? ( X ) b? ( Y ) c? ( J K ) ^^ is actually the main point of my ebuild formatting nazi agenda (usually followed by oh why did you break formatting in my shiny ebuild!11, revert! chants by various developers in case I happened to touch packages of theirs). I never understood the reason after keeping deps not sorted alphabetically where order doesn't matter - it's like someone purposely made ebuild harder to read - it's counter productive. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: split up media-sound/ category
On Tuesday 21 of June 2011 16:24:07 Michał Górny wrote: Hello, As we discussed for a while, the media-sound/ category has grown very large and it may be a good idea to split it. Right now, it contains audio players, editing software, converters, sound systems and a lot of other utilities related to sound. Splitting that up would make looking up software easier for users (e.g. if I want to take a look at what audio players we have, I don't need to see all other programs). What do you think? What new category/-ies do you suggest? I'd suggest to start thinking about dropping broken categories concept and introduce (not necessarily replace instantly) flat, but tagged package list (so that real vector search on tags can be utilized). -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: split up media-sound/ category
On Friday 24 of June 2011 09:55:19 Ciaran McCreesh wrote:
On Fri, 24 Jun 2011 09:52:03 +0200
Jesús J. Guerrero Botella jesus.guerrero.bote...@gmail.com wrote:
You might not like it, but Gentoo categories have always been
directories, not words into metadata.xml.
So tags are in some way related to categories then?
IMHO the best approach is to forget about categories and:
- make package names unique identifiers (it's not that hard, renaming stuff in
app-xemacs mostly) - categories would serve no purpose as id anymore (though
may need to be provided as backward compatibility - but with symlinks to
ebuilds/${PN} inside)
- move such packages into ${PORTDIR}/ebuilds directory (so that identity is
ensured on filesystem level) - 'ebuilds' name doesn't seem to be reserved
anywhere so good candidate imho.
To those concerned with directory lookup speed (in order to find package by
name) - generated package index file provided in ${PORTDIR}
- extend their metadata.xml (no ebuild variables please) with tags in accepted
format. We should provide dictionary for available tags - necessary in order
to avoid randomly added system tags - tag could be extended when needed -
similar policy to global USE flags for instance
- package manager needs to be make aware of tags of course in order to allow
package list (not tree anymore) searching and filtering
(virtual package tree can be generated from tag - by number of tag occurrences
in packages - for instance all packages with tag kde could be shown
somewhere within kde tag subtree etc)
- no tag related symlinks please
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: split up media-sound/ category
On Saturday 25 of June 2011 17:19:47 Duncan wrote:
Maciej Mrozowski posted on Sat, 25 Jun 2011 13:55:40 +0200 as excerpted:
On Friday 24 of June 2011 09:55:19 Ciaran McCreesh wrote:
So tags are in some way related to categories then?
IMHO the best approach is to forget about categories and:
- make package names unique identifiers (it's not that hard, renaming
stuff in app-xemacs mostly) - categories would serve no purpose as id
anymore (though may need to be provided as backward compatibility - but
with symlinks to ebuilds/${PN} inside)
What a beautiful bikeshed we're debating! =:^p
No bikeshedding, just any mean necessary (I'd be fine with anything) in order
to phase out categories from being necessary for critical package manager
operations.
- move such packages into ${PORTDIR}/ebuilds directory (so that identity
is ensured on filesystem level) - 'ebuilds' name doesn't seem to be
reserved anywhere so good candidate imho.
To those concerned with directory lookup speed (in order to find package
by name) - generated package index file provided in ${PORTDIR}
Alternatively, just use first letter subdivisions. Perhaps grouping them
as ac, df, etc, or whatever granularity seems appropriate, if desired.
That's a common method of eliminating large-dir issues with otherwise
flat listings.
Using directory structure as a way to enhance performance is sign of bad
design. Simple
find /usr/portage/ebuilds -type d -maxdepth 1 | sort ebuilds.index should be
sufficient. One can even extract tags in that file and list them after package
name for faster searching.
- extend their metadata.xml (no ebuild variables please) with tags in
accepted format. We should provide dictionary for available tags -
necessary in order to avoid randomly added system tags - tag could be
extended when needed - similar policy to global USE flags for instance
Keep in mind that there has historically been extremely high resistance
to xml-ifying anything critical to operational package management, by
certain highly respected and politically influential gentoo devs.
There's a reason metadata.xml contains only ancillary data, while the
most important operational data (depends, inherits, src_uri, etc) remains
as variables within the ebuilds and/or eclasses.
Yes, and the reason is metadata.xml can contain only version invariant data
and should not contain anything that's required for ebuild.sh. So inherits,
src_uris, dependencies - cannot be placed there. Assuming package names are
unique identifiers, tags are not necessary to be available for ebuild.sh so
metadata.xml is the best place.
I never tracked who was so stridently opposed and it may well be that
they've retired now, but there's some people who simply don't consider xml
a sufficiently robust solution in terms of parsing dependencies AND easy
error-free human parsability.
[...]
Let's not diverge this purely technical topic to who thought what on what
based on sth or there are some people who don't consider xml... and let
them speak on technical matters if they want.
FWIW, I agree that it'd be a step backward in terms of human editability
ease and thus I'd find it a sad day were that to happen, but my feelings
aren't particularly strong on the issue.
But if packages are indeed uniquely and canonically identified by name
only and tags are kept as ancillary to the core merge process as
metadata.xml is now, there shouldn't be a problem with it.
No, tags are no supposed to be critical for package manager operations.
Package manager needs to be aware of them in order to provide useful
searching, but that's about it.
I think we'd just need some simplest proof of concept implementation...
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: split up media-sound/ category
On Saturday 25 of June 2011 19:29:58 Ulrich Mueller wrote:
On Sat, 25 Jun 2011, Maciej Mrozowski wrote:
Assuming package names are unique identifiers, tags are not
necessary to be available for ebuild.sh so metadata.xml is the best
place.
But we know that package names are _not_ unique. There are many cases
in the Portage tree where two or even more packages have the same
name. Categories are there to avoid such collisions.
But we also know, that making package names unique is first step to take as I
already noted in my first post in this thread. It's not that current package
naming scheme should be an unfixable obstacle preventing us from getting rid
of pointless categories (yes, every pkgmove in tree renders categories concept
broken by design, sorry to state this fact brutally).
As far as app-xemacs is concerned (and probably why you commented here), it
should be sufficient to prepend xemacs- to package names from app-xemacs
category in order to make them distinguished from the rest.
It would be elegant and correct - after all when you emerge ocaml you don't
expect to be installing objective caml mode for Emacs, but ocaml interpreter
itself.
With multiple overlays/repositories instead of one monolithic Portage
tree, the collision issue gets even worse if you have a flat
namespace.
Every not Gentoo-based distro can live with unique package names, somehow
Gentoo is not able to? Colour me surprised.
Btw, in above, I specifically proposed those unique packages to be placed in
${PORTDIR}/ebuilds/ because when 'ebuilds' is considered like a fake category'
- existing atom syntax can be used and so can be current package manager
implementation (even with not entirely converted package tree, except
uniqueness is not checked in such case).
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Reviving webapp-config
On Monday 13 of June 2011 11:35:08 Patrick Lauer wrote: On 06/13/11 01:44, Maciej Mrozowski wrote: On Friday 10 of June 2011 20:08:00 Ciaran McCreesh wrote: On Thu, 9 Jun 2011 16:37:46 -0500 Matthew Summers quantumsumm...@gentoo.org wrote: After consultation and discussion at length with several developers, I am writing to announce the impending revival of the tool known as app-admin/webapp-config effective immediately. You might want to chuck it out and start from scratch... Much of the difficulty with the original webapp-config was that it was designed to work on Windows. Stuart's plan was to create a distribution and operating system independent way of dealing with web apps, sort of like CPAN; Gentoo was merely the testbed. If your goals don't match that, you're probably better rethinking everything than trying to revive something that was designed for a completely different purpose. Also, for pure Gentoo needs it may be better to replace webapp-config with package manager and eclasses. How does that handle multiple installs etc.? Multiple version installs? Package slotting could be utilized. If multiple instances of the same version - of course it doesn't but nothing prevents you (or eclass - pkg_config() phase) from creating apache config for each virtualhost (for instance) you want particular webapp served. It's not like one really needs to bluntly copy webapp code to deploy it multiple times, usually it's sufficient to fiddle with DocumentRoot/ and Directory/. Sometimes patches are needed of course. So to install web apps to /usr/share or sth and provide apache config files to set up those webapps like Debian does for instance ZOMG NOES. That stuff is horrible, it randomly patches the webserver config wrongly, then restarts the webserver - so installing nagios knocks out your apache. Which then makes for some funny debugging ... Let's aim higher than that, please, I don't want random misbehaviour :) I forgot the word 'Debian' triggers some unhandled exceptions within your processing queue ;) Seriously, Debian-way of handling web apps isn't bad at all from my experience (I'm not sysadmin however, I just happened to maintain a few web/dev servers), certainly better out-of-the-box experience and better organized than what we have IMHO (save webapp-config). As for httpd service auto restarts - I believe that was never suggested for Gentoo anyway, just a bit Debian-like apache config layout - bug 296271. - so dispatch-conf would be utilized for tracking config file modifications and uninstall via unmerge One major obstacle is that we have quite a number of web servers to support if we're to provide out of the box experience for those web apps. So provide a default config for, say, apache, and then figure out if that can be transcribed to others easily. Maybe it can be turned into simple templates to generate all configs from? -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Reviving webapp-config
On Friday 10 of June 2011 20:08:00 Ciaran McCreesh wrote: On Thu, 9 Jun 2011 16:37:46 -0500 Matthew Summers quantumsumm...@gentoo.org wrote: After consultation and discussion at length with several developers, I am writing to announce the impending revival of the tool known as app-admin/webapp-config effective immediately. You might want to chuck it out and start from scratch... Much of the difficulty with the original webapp-config was that it was designed to work on Windows. Stuart's plan was to create a distribution and operating system independent way of dealing with web apps, sort of like CPAN; Gentoo was merely the testbed. If your goals don't match that, you're probably better rethinking everything than trying to revive something that was designed for a completely different purpose. Also, for pure Gentoo needs it may be better to replace webapp-config with package manager and eclasses. So to install web apps to /usr/share or sth and provide apache config files to set up those webapps like Debian does for instance - so dispatch-conf would be utilized for tracking config file modifications and uninstall via unmerge One major obstacle is that we have quite a number of web servers to support if we're to provide out of the box experience for those web apps. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] introspection use flag
On Saturday 07 of May 2011 01:18:57 Nirbheek Chauhan wrote:
On Fri, May 6, 2011 at 11:34 PM, Maciej Mrozowski reave...@gmail.com
wrote:
On Friday 06 of May 2011 15:18:20 Marijn wrote:
And what happened to the proposed description:
introspection: Add gobject-introspection support, allowing for the
dynamic generation of bindings for various languages
No.
http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg40069.html
It's things like this that convinced us that there's no real advantage
in having it as a global use-flag. Maybe 3 years later when there is
*still* nothing else in the tree that uses introspection besides
gobject-introspection, we'll revisit this and finally make it a global
use-flag.
Nirbheek... and what's particularly wrong with 'introspection' global USE flag
having implementation-agnostic Enable runtime API introspection description?
Nobody sees anything wrong with overly vague 'xml' global USE flag and my
proposition isn't worse ('Add support for XML files' ... you mean what
support? import/export or just expat vs libxml2?)
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] introspection use flag
On Friday 06 of May 2011 15:18:20 Marijn wrote: On 05/06/11 14:25, Gilles Dartiguelongue wrote: Le vendredi 06 mai 2011 à 10:40 +0200, Marijn a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear all, I was just looking into the meaning of the introspection use-flag and there are many ebuilds that use it so perhaps it should be globalized, which would also give us a chance to improve the naming/description. Current descriptions are: Use dev-libs/gobject-introspection for introspection Enable GObject introspection. Currently it is hard to tell which functionality is enabled through this flag and the meaning of the descriptions for when the flag is off are even more unclear. Does it mean that introspection will not be used or will some other way of introspection be used? Either way, perhaps the people in the know could shed some light on this issue? Thanks, Marijn See original thread on this mailing list: From: Arun Raghavan ford_pref...@gentoo.org Subject:[gentoo-dev] New global USE flag: introspection Date: Sun, 20 Jun 2010 20:12:58 +0530 (20/06/2010 16:42:58) Message-ID: aanlktimjjigw6k5vqcx-wryeyy_fputqprn7jmw4x...@mail.gmail.com Thanks for the pointer![1] Having just read that discussion it seems that even back then many developers found that the name introspection is too broad/imprecise. Several alternatives were proposed, like gintrospection, gobject-introspection, gir, api-introspection. I think any of these would have been better than the current name. And what happened to the proposed description: introspection: Add gobject-introspection support, allowing for the dynamic generation of bindings for various languages No. http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg40069.html which at least contains a hint of what the purpose is of this flag? But maybe someone can do even better than that now that this technology has been in use for a while? Marijn [1]:http://marc.info/?l=gentoo-devm=127704501818312w=2 -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] git? [was: Re: Devmanual text on ChangeLogs]
On Sunday 01 of May 2011 12:09:15 Eray Aslan wrote: On Sun, May 01, 2011 at 12:06:47PM +0300, Samuli Suominen wrote: ... the time alone if you have to stop on each package to wait for echangelog to get done just doubles the amount of time you have to put into committing them. That's just not worth the effort. Won't moving the tree to git will make this a moot discussion? These and similar solutions look more and more lika a band-aid to the defecencies of cvs. No, because ChangeLogs could be dropped even now (and generated for rsync using cvs2cl tool) since ebuild history is already available in CVS (sources.gentoo.org). This discussion is about what tree changes are and which aren't relevant enough for users to be redundantly documented in ChangeLog files assuming they're to be kept for now. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Bugzilla - New Default Status Workflow
On Thursday 28 of April 2011 16:07:24 Christian Ruppert wrote: So once again: https://bugs.gentoo.org/docs/en/html/lifecycle.html *Every* new bug filed by a user without editbugs will have UNCONFIRMED (old NEW) as fixed status. *If* we don't enable the UNCONFIRMED status at all then it will CONFIRMED as default but we would enable the UNCONFIRMED status. Bug wranglers can then assign the bug and they also *can* mark it as CONFIRMED *if* they *can* confirm it. The maintainer may change the status to IN_PROGRESS (old ASSIGNED) afterwards. The snipped of my first mail may be a bit confusing... It just means: NEW will become CONFIRMED, NEW has been fully replaced by CONFIRMED so NEW is gone but CONFIRMED is *not* the new default status. CONFIRMED would/could be the default for everybody with editbugs. ASSIGNED gone, replacement: IN_PROGRESS, REOPENED gone, +1 (with comment, see below) It makes a lot more sense (and it's free from enterprisey meaning wrt ASSIGNED and such) I'd leave the default resolution status for newly created bug as UNCONFIRMED also for editbugs-accounts. It's not that it cannot be changed to CONFIRMED in 'new bug' extended form. CLOSED gone. VERIFIED will be added. I have a little worry thought (that may have been addressed somewhere in this thread) - why is VERIFIED being added? To me it's not needed at all and there are people who seem to have the same opinion: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg39023.html -- regards MM signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-pms] Clarify wording on self-blockers
On Wednesday 27 of April 2011 21:24:51 Ciaran McCreesh wrote: Uh, no, that's the entire point of EAPIs. This is a common misconception. Uh, no. You are completely and horribly wrong. EAPIs were introduced to avoid the problems that we used to have where different versions of Portage did different things with the same input (including, but not limited to, difficulties in adding new features). From ebuild developer point of view - EAPI specification should provide all knowledge required to create ebuilds along with detailed and unambiguous description of what to expect from package manager that is compliant with said EAPI. Oh heck no. That really isn't the point at all. But it is. Discussion about blocks is precisely about what is expected package manager behaviour for self-mutual blocks (in EAPI=2) in such case. And what you propose is 'behaviour is undefined for self-mutual blocks' - if so, why are they permitted by specification and not banned instead? The way you understand the word 'specification' doesn't really allow any specs bugfixes since they would magically invalidate any existing implementations, unless there is just one (and actually there *is* just one *supported*) so that specification could be kept in sync with it. How does Paludis handle normal and/or strong self-blocks? And how PkgCore does? Is blocks situation ever going to be clarified/improved in package manager level? What with other PMS issues? No, specification will be out of sync because every single random package manager developer will implement it his/her way, and then claim said package manager is compliant and specification cannot be fixed since it changes behaviour. No, it doesn't change behaviour of any implementation - it will make it possible to determine that some particular implementation is not compliant. It is to mean that some ancient portage is not compliant with hopefully-soon-to-be-updated specification? Yes indeed, that's the result of updating *specification*. Maybe also the point. From an ebuild developer's point of view, PMS describes (or at least tries to describe -- the case under discussion here is one where PMS probably needs fixing) what can and cannot be relied upon from the package manager. The EAPI feature is used to restrict your ebuild's availability to *all* package manager versions supporting a particular set of features. Not the most recent Portage version. *ALL* versions of Portage that claim support for the EAPI in question. (I'm tempted to quote some random definition for fun) Ebuild developer looks at PMS through a view called EAPI so ebuild developer is interested in package manager behaviour in said EAPI that's why I said EAPI not PMS. And Portage is frankly the only supported package manager in Gentoo. If one wanted PMS to document behaviour of all known portage/paludis/pkgcore versions in PMS, one would need to be much more specific: what behaviour applies to what versions of particular package manager so that one really knows what can and what cannot be relied upon. But I suppose it's not the point. I thought PMS is specification and not a documentation - hence it should specify (to document would be poor choice of words.. ) intended, widely agreed behaviour and *defined* behaviour so that ebuild developer knows how to write ebuilds that work against PM *compliant* with specification and package manager developer knows how to write *compliant* PM. And because there are many places where PMS is too vague, it misses those goals. Old package managers and their expected behaviour is irrelevant as soon as migration path to recent version exists for them. Again, you are deeply confused. It is required that an upgrade path for old package managers is kept around for as long as possible by not using newer EAPIs for certain key system packages. This is entirely different to what you're saying -- it means that certain packages should be kept at low EAPIs for as long as possible, not that EAPIs are whatever the latest Portage version does. No, you're making it up here. Since intended behaviour for normal vs strong blocks is like Ulrich specified, and migration path to the most recent from first portage supporting EAPI-2 exists - argument to block specification update is invalid. That doesn't follow at all. What happens if someone has an old Portage installed and the migration path includes things that rely upon a changed behaviour? It wouldn't be a migration path, would it? Since you're trying to retroactively define a particular behaviour for all EAPIs that doesn't match what some old Portage versions do, your upgrade path is screwed. No, I'm supporting *defining* behaviour as it's intended so that package managers are able to know whether they are correct. You're making all of them correct by explicitly allowing them to do anything here and there - it's not helping. This sort of thing really
[gentoo-dev] Re: [gentoo-pms] Clarify wording on self-blockers
On Wednesday 27 of April 2011 23:30:22 Maciej Mrozowski wrote: Please ignore me, unintentional cross-post. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Private SVN repository for live-ebuild
On Friday 28 of January 2011 15:26:27 Donnie Berkholz wrote: On 11:55 Thu 27 Jan , Zac Medico wrote: On 01/27/2011 11:08 AM, Matthew Summers wrote: One question though. Since the 'portage' user has its $home set by default to /var/tmp/portage how would you recommend handling the ssh key situation since that directory is somewhat special? Well, I've never tried it, so I don't have any recommendation atm other than to make sure FEATURES=userpriv is not enabled. Moving forward, maybe it would make sense to have a notion of a configurable fetcher home that package managers and live/vcs eclasses would use for the HOME variable only when fetching. For example, the user could configure this by setting a FETCHER_HOME variable. This might be useful in other scenarios besides fetching that just haven't occurred to us yet. Perhaps we should treat the portage user as a regular user with a regular home directory that can be configured as desired, and flip in and out of that user on demand. Having SCM distfiles in user directory is not new 'market demand'. Below there's subversion eclass enhancement request I opened some time ago which I used to work around so far by denying emerge write access to distfiles. https://bugs.gentoo.org/show_bug.cgi?id=277976 -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [warning] the bug queue has 118 bugs
On Wednesday 15 of December 2010 17:03:12 Matt Turner wrote: On Wed, Dec 15, 2010 at 12:25 PM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: By the way, we have a nice team of arch and herd testers - how about encouraging them to wrangle some bugs? Yeah, I just came here to say this. One certainly doesn't need to have completed the developer quizzes to sort bugs. Well, before I became developer, I had a quite unproductive discussion on IRC with Jeroen on that matter (jer opting for status quo and telling me I have no idea what bug wrangling is :P) It all started by Yngwin's post: http://forums.gentoo.org/viewtopic-t-702248-highlight-contributions.html Some ideas were proposed such as lowering requirements for bug wranglers or recruiting them as staff (so bypassing ebuild quizzes). -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Change policy about live ebuilds
On Thursday 25 of November 2010 16:07:45 Alexis Ballier wrote: On Thursday 25 November 2010 11:22:39 Paweł Hajdan, Jr. wrote: On 11/25/10 2:59 PM, Alexis Ballier wrote: I fail to understand why you claim that live ebuilds are a QA nightmare, you may want to have a look at how I play with, eg, ffmpeg or vlc and their live ebuilds: they make version bumps much easier and far less error prone. I'm just curious. Could you explain more how the live ebuilds make version bumps easier and less error prone? By following closely upstream development you are able to adapt the live ebuild to the current status, eg, for new deps. Usually with vlc, when a new major version comes out, there are a couple of new features and a couple of outdated features removed, doing all these changes at once is more error prone than doing it once you notice the change for each of them in the live ebuild. As for version bumps, the live ebuild is simply copied to an ebuild with a name matching the version that has just been released. It may be worth mentioning it's exactly how all kde-base ebuilds are prepared. We just svn up in distfiles occasionally, look for changes in buildsystem and adjust live (stable branch or trunk) ebuilds accordingly (that being said 4.x. live ebuilds usually reflect the best KDE version available). Many Gentoo KDE devs use 4.x. on daily basis (and actually they should) and thus are able to evaluate patches and take them directly from disfiles via svn diff -r prev:patchrev to tree if needed. Ebuilds you see in tree are just generated versions of live ones (blind copy with replaced keywords, we use bump tool for it however). -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] What the hell is going on here?
On Friday 17 of September 2010 12:41:51 Angelo Arrifano wrote: Every single QA commit review coming into my Inbox during the past week was directed to arfrever. I *know* he is on probation, I *know* he made mistakes - in fact every one makes mistakes. But you guys are hammering all over him for picky stuff. Remind you that while it is a pleasure to be member of Gentoo, we are not your slaves; we chose to spend our free time contributing to Gentoo for several reasons - fun, knowledge and team work. Satisfying somebody else's flavors and wishes is certainly *not* one of them. I never had the chance to talk with arfrever, nor I ever looked to his work at Gentoo. But there is one thing I definitely got right, he has a lot of motivation to continue in Gentoo and *offer* his time and knowledge, otherwise he would just raise the middle finger and go away after all of this bashing. The other important thing is such lecturing should probably take place in private, like gentoo-core. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] What the hell is going on here?
On Friday 17 of September 2010 16:52:03 Markos Chandras wrote: On Fri, Sep 17, 2010 at 12:51:52PM +0200, Maciej Mrozowski wrote: On Friday 17 of September 2010 12:41:51 Angelo Arrifano wrote: Every single QA commit review coming into my Inbox during the past week was directed to arfrever. I *know* he is on probation, I *know* he made mistakes - in fact every one makes mistakes. But you guys are hammering all over him for picky stuff. Remind you that while it is a pleasure to be member of Gentoo, we are not your slaves; we chose to spend our free time contributing to Gentoo for several reasons - fun, knowledge and team work. Satisfying somebody else's flavors and wishes is certainly *not* one of them. I never had the chance to talk with arfrever, nor I ever looked to his work at Gentoo. But there is one thing I definitely got right, he has a lot of motivation to continue in Gentoo and *offer* his time and knowledge, otherwise he would just raise the middle finger and go away after all of this bashing. The other important thing is such lecturing should probably take place in private, like gentoo-core. Well, Angelo is quite right for posting in this ML because QA members wants anything to be publicly visible. No, I mean, lecturing Arfrever should take place in private... -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Closing bugs
On Saturday 11 of September 2010 20:51:56 justin wrote: Hi all, is the following comment an adequate way to close bugs with RESOLVED/INVALID? If so, I will change the way I handle bugs and use it too. virtual/os-headers: 2.6.35 (sys-kernel/linux-headers) ACCEPT_KEYWORDS=amd64 you mix stable unstable - your problem This is common misconception. Let me quote myself from on of Diego's blogs, accusing me of not giving a crap about quality wrt FEATURES=test. Some people say that mixing testing and stable subtrees is ‘broken’ and not supported. It is because they apparently have no idea how package stabilization process works. ‘tinderbox’ idea of full ~arch integration tests is broken by design! Why? Gentoo is distribution with rolling updates and packages being stabilized are hand picked from ~arch and integrated within existing stable environment (along with possible dependencies). Now the question arises – since Gentoo stable is our ultimate target release (and not ~arch) - what is the point in testing how these packages interact with full testing ~arch? The answer is NONE! If any, following tests should be run: - regression tests – ONLY within full stable arch, typical tinderbox of just chroot would fit there well, it could prevent issues like Gentoo LiveCD autobuilds failing since 8 April… - integration tests – in similar way stabilization process is performed: stable system as a base, picking packages or package sets for tests along with their possible dependencies (best version visible, if not visible within stable arch, then best visible within testing arch or some other algorithm, usually just relying on ebuild dependencies) and testing whether it works so that stabilization process is a formality. Running ~arch as 'test' platform is in many cases counter productive. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-python/hachoir-parser: ChangeLog hachoir-parser-1.3.4.ebuild
On Saturday 11 of September 2010 22:18:32 Petteri Räty wrote: On 09/11/2010 11:14 PM, Ryan Hill wrote: On Sat, 11 Sep 2010 22:10:51 +0300 Petteri Räty betelge...@gentoo.org wrote: + +*hachoir-parser-1.3.4 (10 Sep 2010) + + 10 Sep 2010; Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org + -hachoir-parser-1.3.3.ebuild, +hachoir-parser-1.3.4.ebuild: + Version bump. Deleting an older version is relevant so it should also be mentioned in the ChangeLog message. It says -hachoir-parser-1.3.3.ebuild. What exactly do you think would be gained by adding Remove old in this case? Following your logic we should not write Version bump either (as that's what happens by default when you add a new ebuild). Considering the fact, that ChangeLogs are files that contribute to rsync/cvs fetch the most, it's not that bad idea... -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] New eclass: scons.eclass
On Tuesday 24 of August 2010 10:30:12 Michał Górny wrote: On Mon, 23 Aug 2010 19:36:50 +0200 Maciej Mrozowski reave...@gmail.com wrote: If SCons is unpredictable, then don't provide *any* phases and only functions and rename it to scons-utils to match its purpose. It is as predictable as the buildsystem meeting the default phase functions requirements -- we can configure it, compile it but no way of knowing what should be done in 'install' for sure. What I hate is deliberately introduced inconsistency in ebuild API's. What I hate is replicating bad practices just because someone else did that before. If I'm wrong, then please point me the relation between a particular buildsystem and patching. Ideologically there's none, but practically build system may need patching in eclass to fit Gentoo needs. And it's better to do it officially in eclass src_prepare phase than hack around elsewhere. Either provide all buildsystem related phases or none - I'm already tired of playing guess which phase from which eclass takes precedence when multiple inheritance is used game. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: New eclass: scons.eclass
On Monday 23 of August 2010 17:11:47 Michał Górny wrote: On Sun, 22 Aug 2010 23:03:44 +0200 Maciej Mrozowski reave...@gmail.com wrote: I'd suggest providing all src_* phases except src_unpack. Providing a blank src_configure() would be fine but... Even src_prepare that calls base_src_prepare - to get PATCHES and epatch_user support - for simplicity requiring EAPI-2 as providing src_unpack in buildsystem eclasses is a bad design (like providing src_prepare in scm eclasses - this one is yet to be fixed). Why would I do that? If an ebuild needs to use base_src_prepare(), why can't it simply inherit the base eclass? Nothing buildsystem-specific needs to be done in src_prepare() here. And requiring EAPI=2 is even more pointless as SCons doesn't mostly distinguish between 'configure' and 'build' phases. Because if you're to provide src_prepare, for EAPI2 you need to provide src_unpack as well but it's wrong in buildsystem eclasses as I already pointed out (since src_unpack:EAPI1 - src_unpack:EAPI2 + src_prepare:EAPI2), and requiring EAPI-2 allows you to avoid it. If you don't care for PATCHES or user_patches and hence compliance with other buildsystem eclasses, feel free. Also calling base_src_install in scons_src_install if possible would be nice (DOCS, HTML_DOCS support) - to make it resemble cmake-utils, autotools-utils, and a bit of distutils, qt4-edge and gnome2 eclasses. Even more pointless. Although we can assume many of the SConstruct files use the name 'install' for their 'install' target, we can't do that for 'DESTDIR' or how a particular project calls it. Not to mention some don't provide such a thing at all. Every SCons-based ebuild should redefine src_install(). Like I said, if you don't care for consistency with the rest, feel free to ignore. If SCons is unpredictable, then don't provide *any* phases and only functions and rename it to scons-utils to match its purpose (we're quite likely planning to rename cmake-utils.eclass to cmake.eclass for said consistency, unfortunately it was introduced in first place with such name and provided phases). What I hate is deliberately introduced inconsistency in ebuild API's. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: New eclass: scons.eclass
On Sunday 22 of August 2010 20:39:23 Michał Górny wrote: Here goes the second revision. A short changelog: 83678d1 Export a default pkg_setup() and src_compile(). 7f9b565 Introduce escons() function (similar to emake). 19b7e14 Use underscores instead of dashes in function names. Attaching both the new rev and a diff against the first one. I'd suggest providing all src_* phases except src_unpack. Even src_prepare that calls base_src_prepare - to get PATCHES and epatch_user support - for simplicity requiring EAPI-2 as providing src_unpack in buildsystem eclasses is a bad design (like providing src_prepare in scm eclasses - this one is yet to be fixed). Also calling base_src_install in scons_src_install if possible would be nice (DOCS, HTML_DOCS support) - to make it resemble cmake-utils, autotools-utils, and a bit of distutils, qt4-edge and gnome2 eclasses. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Why (i.e. USE=openssl instead of USE=ssl)
On Saturday 14 of August 2010 18:28:19 Peter Hjalmarsson wrote: lör 2010-08-14 klockan 13:45 +0200 skrev Chí-Thanh Christopher Nguyễn: Peter Hjalmarsson schrieb: This is about my beloved USE=ssl. A bit long and ranty, but if you want the consensus, just read the last part. Today a new snapshot of gnash was uploaded where the old USE=ssl was renamed to USE=openssl. So yet another package where if you want ssl support you have to _personally_ audit what function this useflag has (i.e. does it enable ssl or tune the ssl implementation?). So I wanted to figure it out, does gnash provide ssl itself and the USE=openssl only tunes how it is implemented or does USE=openssl enable ssl? The USE flag was renamed after discussion with upstream. Gnash does not provide any SSL implementation itself and (when invoked as NPAPI plugin) uses the browser's facilities. Possibly I could make more explicit that users only interested in the plugin don't need it. Best regards, Chí-Thanh Christopher Nguyễn Well if that is the use of the use flag the description is to be honest really bad. And still, why openssl instead of ssl? Even if most people are out to only get the plugin the meaning of use flag for the rest of the package is still the same. So is there a special reson why upstream do want ssl disabled for people only out to get the plugin (and why not EAPI=1 and IUSE=-ssl)? Because it won't work. Take a look at make.conf(5) manual page - USE_ORDER=env:pkg:conf:defaults:pkginternal:env.d - USE defaults in profile will override pkginternal (IUSE defaults in ebuild). That being said IUSE=-foo is no-op. Otherwise I agree with you wrt naming inconsistencies. I would also like to see some USE defaults from make.defaults moved to package.use, and some package.use defaults moved to IUSE defaults (and some make.defaults dropped completely, like freaking python and perl USE flags - bug 250179) -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] nsbrowser plugins
On Wednesday 11 of August 2010 05:50:47 Paweł Hajdan, Jr. wrote: On 8/10/10 4:28 PM, Jeroen Roovers wrote: Gentoo uses /usr/$(get_libdir)/nsbrowser/plugins for browser plugins. However, Debian uses /usr/$(get_libdir)/mozilla/plugins, and that's what many software projects (including Chromium) target. Could you name them? Opera looks into tons of directories. Sorry, I used a weasel word many software projects without naming them. I don't know packages other than www-client/chromium that would have problems with this. You would then need to re-emerge all users of this eclass. I see. This puts some burden for our users with no obvious gains. What's bugging Chromium? Why does it insist on using a competing browser vendor's name instead of the much more neutral nsbrowser, which generally denotes browsers with a Netscape style plugin interface? Well, the fact that every distributions chooses its own directory for NPAPI plugins is sort of sad. The number of directories that have to be searched for plugins is ridiculously long. I was talking with Evan Martin, a Chromium developer, and he asked whether Gentoo could switch to mozilla/plugins, so I started this thread. After the results, my patch to add nsbrowser/plugins to the plugins search path is probably going to be accepted. By the way, I just wonder... why not _symlink_ mozilla/plugins to nsbrowser/plugins? That would solve the technical problem, while keeping a good, more general name. How about asking Evan Martin (and other browser developers) to add means to specify netscape plugin paths for plugin lookup, either as UI element or at compilation time. The former is exactly what konqueror provides for instance on so it can scan for plugins in many locations (including ~/ for some private/local plugins). Hardcoding paths is a bad design™. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] News item announcing as-needed (glep 42 stuff)
On Tuesday 27 of July 2010 16:39:01 Jeroen Roovers wrote: On Mon, 26 Jul 2010 22:29:06 +0200 Tomáš Chvátal scarab...@gentoo.org wrote: Is it time yet? I still find a lot of packages that do not even respect LDFLAGS yet - when all these get fixed to respect LDFLAGS, we will probably find yet more packages that are problematic with --as-needed. A few broken apps don't overweight the benefit of having --as-needed enabled by default. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: New global USE flag: introspection
On Tuesday 22 of June 2010 19:14:38 Arun Raghavan wrote:
On 20 June 2010 20:12, Arun Raghavan ford_pref...@gentoo.org wrote:
[...]
Any objections? I'll wait till Wed (June 23rd) before adding this if
there aren't any.
Is anyone here vehemently against introspection.
Not vehemently, but how would you differentiate between gobject introspection
or (let's say) DBus introspection or Kross (if anyone writes one).
'introspection' global USE flag simply cannot be described as:
Use pkgdev-libs/gobject-introspection/pkg for introspection/flag
because the term introspection is not specific to GObject. Period.
Now, I don't want to sound harsh, but I understand in Gnome camp (upstream)
there's a tendency to use commonly used names for Gnome specific
technologies. For instance - there's WebKitGtk but tarballs is called (yes,
you guessed it) - webkit-${PV}.tar.gz. It's like for many Desktop Environment
means Gnome, Linux means Ubuntu and such.
The same applies to GObject introspection - in autotools there's --enable-
introspection switch for it like the term introspection was exclusive for
GObject. Also many upstream developers working with Gnome/Gtk/Glib libs and
using said GObject introspection will defend their right to hijack this term
(like certain developer of a library I maintain in Gentoo).
I'd prefer not to see such practice here.
I'd suggest gobject-introspection USE flag instead - it's self describing.
If 'introspection' USE flag is to be used globally, it needs to have
description implementation-agnostic, let's say:
Enable runtime API introspection
or something like this.
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] New eclass: autotools-utils.eclass
On Sunday 18 of July 2010 03:54:43 Jorge Manuel B. S. Vicetto wrote:
grep EAPI-TOO-OLD $(portageq portdir)/eclass/*
/home/gentoo-cvs/gentoo-x86/eclass/kde4-functions.eclass: *)
DEPEND=EAPI-TOO-OLD ;;
/home/gentoo-cvs/gentoo-x86/eclass/poppler.eclass:has 2 ${EAPI} ||
DEPEND=EAPI-TOO-OLD
/home/gentoo-cvs/gentoo-x86/eclass/virtuoso.eclass: *)
DEPEND='EAPI-TOO-OLD' ;;
status quo should be challenged occasionally.
Fixed autotools-utils.eclass, kde4-functions.eclass, virtuoso.eclass
case ${EAPI:-0} in
2|3|4) ;;
- *) DEPEND=EAPI-TOO-OLD ;;
+ *) die EAPI=${EAPI} is not supported ;;
esac
Remaining poppler.eclass is not used anymore and probably subject to remove.
--
regards
MM
[gentoo-dev] New eclass: autotools-utils.eclass
After gathering some feedback, after addressing reported issues, now I feel
it's ready for public consumption. especially when static-libs is being used
more and more often. It's purpose is to become standard eclass for autotools
build systems.
Brief description:
autotools-utils.eclass is autotools.eclass (so libtool.eclass) and base.eclass
(so eutils.eclass) wrapper providing all inherited features (it is guaranteed,
no need to additionally inherit any of those) along with econf arguments as
Bash array, out of source build with overridable build dir location, static
archives handling, libtool files removal, enable/disable debug handling. It's
modelled after cmake-utils and resembles it in many aspects for consistency.
Notable features:
- eautoreconf, eautomake, elibtoolize, eaclocal functions (from autotools)
- PATCHES and user patches support (from base)
- DOCS and HTML_DOCS arrays support (from base)
- myeconfargs - econf arguments as Bash array (usage like mycmakeargs in
cmake-utils, if used, needs to be defined just before autotools-
utils_src_configure call)
- out of source build (enabled by default) with overridable build dir location
- static archives handling (static-libs in IUSE)
- automatic removal of unnecessary static archives (usually for plugins,
determined by presence of shouldnotlink=yes libtool property)
- libtool files removal (static-libs in IUSE, determined by absence of
shouldnotlink=yes libtool property)
- enable/disable-debug handing (debug in IUSE)
- remove_libtool_files function to help override libtool removal behaviour
(you shouldn't need it, any usage or this function with parameter 'none' will
be reported and punished :p)
Restrictions:
- only = EAPI-2 supported (this is intentional as src_prepare phase is
provided, EAPI-0,1 would mean providing src_unpack as well, which is
unacceptable for build system eclasses)
Attached two example ebuilds.
Refer to eclass manual page for details or more extensive example usage.
--
regards
MM
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: autotools-utils.eclass
# @MAINTAINER:
# Maciej Mrozowski reave...@gentoo.org
# @BLURB: common ebuild functions for autotools-based packages
# @DESCRIPTION:
# autotools-utils.eclass is autotools.eclass(5) and base.eclass(5) wrapper
# providing all inherited features along with econf arguments as Bash array,
# out of source build with overridable build dir location, static archives
# handling, libtool files removal, enable/disable debug handling.
#
# @EXAMPLE:
# Typical ebuild using autotools-utils.eclass:
#
# @CODE
# EAPI=2
#
# inherit autotools-utils
#
# DESCRIPTION=Foo bar application
# HOMEPAGE=http://example.org/foo/;
# SRC_URI=mirror://sourceforge/foo/${P}.tar.bz2
#
# LICENSE=LGPL-2.1
# KEYWORDS=
# SLOT=0
# IUSE=debug doc examples qt4 static-libs tiff
#
# CDEPEND=
# media-libs/libpng:0
# qt4? (
# x11-libs/qt-core:4
# x11-libs/qt-gui:4
# )
# tiff? ( media-libs/tiff:0 )
#
# RDEPEND=${CDEPEND}
# !media-gfx/bar
#
# DEPEND=${CDEPEND}
# doc? ( app-doc/doxygen )
#
#
# # bug 123456
# AUTOTOOLS_IN_SOURCE_BUILD=1
#
# DOCS=(AUTHORS ChangeLog README Read me.txt TODO)
#
# PATCHES=(
# ${FILESDIR}/${P}-gcc44.patch # bug 123458
# ${FILESDIR}/${P}-as-needed.patch
# ${FILESDIR}/${P}-unbundle_libpng.patch
# )
#
# src_configure() {
# myeconfargs=(
# $(use_with qt4)
# $(use_enable threads multithreading)
# $(use_with tiff)
# )
# autotools-utils_src_configure
# }
#
# src_compile() {
# autotools-utils_src_compile
# use doc autotools-utils_src_compile docs
# }
#
# src_install() {
# use doc HTML_DOCS=(${AUTOTOOLS_BUILD_DIR}/apidocs/html/)
# autotools-utils_src_install
# if use examples; then
# dobin ${AUTOTOOLS_BUILD_DIR}/foo_example{1,2,3} \\
# || die 'dobin examples failed'
# fi
# }
#
# @CODE
# Keep variable names synced with cmake-utils and the other way around!
case ${EAPI:-0} in
2|3|4) ;;
*) DEPEND=EAPI-TOO-OLD ;;
esac
inherit autotools base
EXPORT_FUNCTIONS src_prepare src_configure src_compile src_install src_test
# @ECLASS-VARIABLE: AUTOTOOLS_BUILD_DIR
# @DESCRIPTION:
# Build directory, location where all autotools generated files should be
# placed. For out of source builds it defaults to ${WORKDIR}/${P}_build.
# @ECLASS-VARIABLE: AUTOTOOLS_IN_SOURCE_BUILD
# @DESCRIPTION:
# Set to enable in-source build.
# @ECLASS-VARIABLE: ECONF_SOURCE
# @DESCRIPTION:
# Specify location of autotools' configure script. By default it uses ${S}.
# @ECLASS-VARIABLE: myeconfargs
# @DESCRIPTION:
# Optional econf arguments as Bash array. Should be defined before calling
src_configure.
# @CODE
# src_configure() {
# myeconfargs=(
# --disable-readline
# --with-confdir
Re: [gentoo-dev] New eclass: autotools-utils.eclass
On Saturday 17 of July 2010 13:03:33 Petteri Räty wrote: On 07/17/2010 01:53 PM, Maciej Mrozowski wrote: After gathering some feedback, after addressing reported issues, now I feel it's ready for public consumption. especially when static-libs is being used more and more often. It's purpose is to become standard eclass for autotools build systems. Brief description: autotools-utils.eclass is autotools.eclass (so libtool.eclass) and base.eclass (so eutils.eclass) wrapper providing all inherited features (it is guaranteed, no need to additionally inherit any of those) along with econf arguments as Bash array, out of source build with overridable build dir location, static archives handling, libtool files removal, enable/disable debug handling. It's modelled after cmake-utils and resembles it in many aspects for consistency. Maybe choose some other name. For me -utils in an eclass name means a set of helper functions. I would name it so the name reflects that it's meant to be used as the main build system provider. It's for consistency with existing cmake-utils.eclass, which is main cmake buildsystem provider (no idea why it wasn't called just 'cmake' by initial commiters). Unfortunately autotools name is already taken and extending autotools so much (adding new defined phases) is not possible (nor is renaming) as far as I understand. -- regards MM
Re: [gentoo-dev] Re: Over using preserve_old_lib, don't do that
On Thursday 15 of July 2010 12:14:29 Duncan wrote: Gilles Dartiguelongue posted on Thu, 15 Jul 2010 11:09:39 +0200 as excerpted: Le jeudi 15 juillet 2010 à 09:49 +0100, Mike Auty a écrit : [...] I can live with this for in places where it causes massive breakage (openssl/libpng/libjpg), because it's genuinely useful, but I think it should be restricted to such important packages, or at least disabled by FEATURES=-preserve-libs. Ideally, these calls should either adhere to FEATURES=-preserve-libs, or there should be a tool that can identify which files portage has preserved, and allow easy rebuilding of dependent packages, and removal. At the moment, I'm having to manually grep ebuilds, ls the libraries and run revdep-rebuild over them one at a time... These sound like very good ideas to me. ++ If I have FEATURE=-preserve-libs, that's what I want. Exceptions should be limited to what will break the toolchain (including revdep-rebuild here, since that's what's normally used to get out of the situation) itself. If there was a way to handle it so a general revdep-rebuild run would still detect the preserved library as missing and do the necessary rebuilds, it'd be one thing, but if the libraries are there, it figures things are OK unless you've fed it that specific library, thereby making a general revdep-rebuld run useless at the very task it was designed to fix. Talking about which... What about creating an eutils (or whatever) function to handle the critical preservations, having it build a centralized list of them somewhere, and having a revdep-rebuild mode that will treat that list as if it had been fed in with --library on the command line? Make revdep-rebuild able to run this mode either on its own, or as part of an otherwise general run, and then you can have packages (or the package-manager itself, if it uses the list as well) preserve libs as they wish, without interfering with the ability of revdep- rebuild to detect and resolve the issues in a normal run. And what about using portage 2.2 and be done with it. I don't see the point in reinventing the wheel yet again. Imho, revdep-rebuild and all 'misc' tools requiring users' good will like python-updater should be obsolete and phased out in favour of package manager controlled mechanisms. -- regards MM
Re: [gentoo-dev] Re: Over using preserve_old_lib, don't do that
On Thursday 15 of July 2010 16:24:08 Mike Auty wrote: On 15/07/10 14:57, Maciej Mrozowski wrote: And what about using portage 2.2 and be done with it. I don't see the point in reinventing the wheel yet again. I'm using portage-2.2 and have been since it first came out. I find the @set notation invaluable. From my perspective sets notation is actually worthless and confusing (but that's another topic). IIRC I've already spoke with portage team to think about making it emerge option instead or at least decouple it from sets semantics if possible (or it was about @live-rebuild? hmm). I think there are some preserved-related bugs (false positives) that need to be fixed first. Otherwise I'd welcome it being stable. I've already forgot what revdep-rebuild is thanks to portage-2.2 -- regards MM
Re: [gentoo-dev] Re: [Survey || RFC] autotools-utils.eclass
On Wednesday 07 of July 2010 02:16:13 Maciej Mrozowski wrote:
On Thursday 03 of June 2010 01:32:09 Nathan Phillip Brink wrote:
On Mon, May 31, 2010 at 03:29:01PM +0200, Maciej Mrozowski wrote:
On Wednesday 26 of May 2010 19:27:43 Mike Frysinger wrote:
On Wednesday 26 May 2010 05:38:00 Maciej Mrozowski wrote:
I've updated documentation, added example usage and option to keep
libtool files (ltdl.so supposedly needs those as I was told, no
idea what for).
IMO, ltdl.so is probably just being silly. Perhaps these files contain
information that is useful on non-Linux systems for dlopen()ing
plugins.
more applicable to us w/Linux is that static linking with libtool
needs them. the AUTOTOOLS_KEEP_LA_FILES seems kind of spurious
considering current tree behavior and assumption of gnu-capable
linking systems.
It is spurious when we forget about run-time dynamic linking (plugins)
in some apps.
libtool loader (ltdl.so) needs .la files unfortunately. One example -
imagemagick - removing .la files for coders makes 'convert' unable to
locate them (silly, but hey...).
This case can be caught by checking if the .la file has the following in
it: ``
# Should we warn about portability when linking against -modules?
shouldnotlink=yes
''
Excellent. Eclass updated, see attachment. AUTOTOOLS_KEEP_LA_FILES option
removed. Now removing .la files relies only on shouldnotlink value (and
static-libs presence in IUSE that is).
Removing .la files which are useless on a given system would be very
nice. It would be even more useful if unused .a files could be swept
away at the same time :-).
They are - just add static-libs to IUSE and disable said USE flag when
emerging.
I've also had an idea to be smarter and to look for patches (PATCHES array)
updating any .m4, Makefile.{ac,in}, configure.{ac.in} files and to run
eautoreconf automatically in ${eclass}_src_prepare but I've decided it's a
bit too much. I may rethink the idea later though.
If there are no objections nor further comments, I'd like to unleash new
eclass for public consumption within a few days.
Before I do so, please comment on the following changes I've made:
- always pass --disable-dependency-tracking
- always remove static libs corresponding to plugins (based on
shouldnotlink=yes)
- add remove_libtool_files [all|none] function
- add some low-profile echo messages showing removed files
- append myeconfargs at the end of econfargs so that eclass defaults can be
overriden at request
http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=history;f=eclass/autotools-
utils.eclass
If there are no further issues, I'll commit it to tree (with announcement)
within three or more days.
--
regards
MM
Re: [gentoo-dev] Re: [Survey || RFC] autotools-utils.eclass
On Thursday 03 of June 2010 01:32:09 Nathan Phillip Brink wrote:
On Mon, May 31, 2010 at 03:29:01PM +0200, Maciej Mrozowski wrote:
On Wednesday 26 of May 2010 19:27:43 Mike Frysinger wrote:
On Wednesday 26 May 2010 05:38:00 Maciej Mrozowski wrote:
I've updated documentation, added example usage and option to keep
libtool files (ltdl.so supposedly needs those as I was told, no idea
what for).
IMO, ltdl.so is probably just being silly. Perhaps these files contain
information that is useful on non-Linux systems for dlopen()ing
plugins.
more applicable to us w/Linux is that static linking with libtool needs
them. the AUTOTOOLS_KEEP_LA_FILES seems kind of spurious considering
current tree behavior and assumption of gnu-capable linking systems.
It is spurious when we forget about run-time dynamic linking (plugins) in
some apps.
libtool loader (ltdl.so) needs .la files unfortunately. One example -
imagemagick - removing .la files for coders makes 'convert' unable to
locate them (silly, but hey...).
This case can be caught by checking if the .la file has the following in
it: ``
# Should we warn about portability when linking against -modules?
shouldnotlink=yes
''
Excellent. Eclass updated, see attachment. AUTOTOOLS_KEEP_LA_FILES option
removed. Now removing .la files relies only on shouldnotlink value (and
static-libs presence in IUSE that is).
Removing .la files which are useless on a given system would be very
nice. It would be even more useful if unused .a files could be swept
away at the same time :-).
They are - just add static-libs to IUSE and disable said USE flag when
emerging.
I've also had an idea to be smarter and to look for patches (PATCHES array)
updating any .m4, Makefile.{ac,in}, configure.{ac.in} files and to run
eautoreconf automatically in ${eclass}_src_prepare but I've decided it's a bit
too much. I may rethink the idea later though.
If there are no objections nor further comments, I'd like to unleash new
eclass for public consumption within a few days.
Real-world example ebuild attached, also there's more extensive (but purely
academic) example in eclass itself.
--
regards
MM
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: autotools-utils.eclass
# @MAINTAINER:
# Maciej Mrozowski reave...@gentoo.org
# @BLURB: common ebuild functions for autotools-based packages
# @DESCRIPTION:
# autotools-utils.eclass is autotools.eclass(5) and base.eclass(5) wrapper
# providing all inherited features along with econf arguments as Bash array,
# out of source build with overridable build dir location, static archives
# handling, libtool files removal, enable/disable debug handling.
#
# @EXAMPLE:
# Typical ebuild using autotools-utils.eclass:
#
# @CODE
# EAPI=2
#
# inherit autotools-utils
#
# DESCRIPTION=Foo bar application
# HOMEPAGE=http://example.org/foo/;
# SRC_URI=mirror://sourceforge/foo/${P}.tar.bz2
#
# LICENSE=LGPL-2.1
# KEYWORDS=
# SLOT=0
# IUSE=debug doc examples qt4 static-libs tiff
#
# CDEPEND=
# media-libs/libpng:0
# qt4? (
# x11-libs/qt-core:4
# x11-libs/qt-gui:4
# )
# tiff? ( media-libs/tiff:0 )
#
# RDEPEND=${CDEPEND}
# !media-gfx/bar
#
# DEPEND=${CDEPEND}
# doc? ( app-doc/doxygen )
#
#
# # bug 123456
# AUTOTOOLS_IN_SOURCE_BUILD=1
#
# DOCS=(AUTHORS ChangeLog README Read me.txt TODO)
#
# PATCHES=(
# ${FILESDIR}/${P}-gcc44.patch # bug 123458
# ${FILESDIR}/${P}-as-needed.patch
# ${FILESDIR}/${P}-unbundle_libpng.patch
# )
#
# src_configure() {
# myeconfargs=(
# $(use_with qt4)
# $(use_enable threads multithreading)
# $(use_with tiff)
# )
# autotools-utils_src_configure
# }
#
# src_compile() {
# autotools-utils_src_compile
# use doc autotools-utils_src_compile docs
# }
#
# src_install() {
# use doc HTML_DOCS=(${AUTOTOOLS_BUILD_DIR}/apidocs/html/)
# autotools-utils_src_install
# if use examples; then
# dobin ${AUTOTOOLS_BUILD_DIR}/foo_example{1,2,3} \\
# || die 'dobin examples failed'
# fi
# }
#
# @CODE
# Keep variable names synced with cmake-utils and the other way around!
case ${EAPI:-0} in
2|3|4) ;;
*) DEPEND=EAPI-TOO-OLD ;;
esac
inherit autotools base
EXPORT_FUNCTIONS src_prepare src_configure src_compile src_install src_test
# @ECLASS-VARIABLE: AUTOTOOLS_BUILD_DIR
# @DESCRIPTION:
# Build directory, location where all autotools generated files should be
# placed. For out of source builds it defaults to ${WORKDIR}/${P}_build.
# @ECLASS-VARIABLE: AUTOTOOLS_IN_SOURCE_BUILD
# @DESCRIPTION:
# Set to enable in-source build.
# @ECLASS-VARIABLE: ECONF_SOURCE
# @DESCRIPTION:
# Specify location of autotools' configure script. By default it uses ${S}.
# @ECLASS-VARIABLE: myeconfargs
# @DESCRIPTION:
# Optional econf
Re: [gentoo-dev] New global USE flag: introspection
On Sunday 20 of June 2010 16:42:58 Arun Raghavan wrote: Hi folks, I'd like to propose a new global USE-flag: introspection. The purpose of the flag is to enable the building of GIR for the package using dev-libs/gobject-introspection. gobject-introspection is going to be quite important in upcoming GNOME releases, allowing for the automated generation of bindings for several languages. We already have 13 packages using this flag, with several more to come. The current description being used in packages' metadata.xml sucks - I'll put something more descriptive in the final flag. Any objections? I'll wait till Wed (June 23rd) before adding this if there aren't any. I don't mind adding it as globally recognizable USE flag, I'd mind however having it enabled by default in desktop/base profile. If Gnome needs it, please enable it in gnome subprofile if you wish (apart from setting all required USE deps in ebuilds), you can also use IUSE defaults for it which would allow more fine grained control or if you or Gnome devs decided to drop the idea at some point. -- regards MM
Re: [gentoo-dev] New global USE flag: introspection
On Monday 21 of June 2010 16:22:08 Olivier Crête wrote: On Mon, 2010-06-21 at 09:33 +0200, Maciej Mrozowski wrote: On Sunday 20 of June 2010 16:42:58 Arun Raghavan wrote: Hi folks, I'd like to propose a new global USE-flag: introspection. The purpose of the flag is to enable the building of GIR for the package using dev-libs/gobject-introspection. gobject-introspection is going to be quite important in upcoming GNOME releases, allowing for the automated generation of bindings for several languages. We already have 13 packages using this flag, with several more to come. The current description being used in packages' metadata.xml sucks - I'll put something more descriptive in the final flag. Any objections? I'll wait till Wed (June 23rd) before adding this if there aren't any. I don't mind adding it as globally recognizable USE flag, I'd mind however having it enabled by default in desktop/base profile. If Gnome needs it, please enable it in gnome subprofile if you wish (apart from setting all required USE deps in ebuilds), you can also use IUSE defaults for it which would allow more fine grained control or if you or Gnome devs decided to drop the idea at some point. Oh no! You'll have two small data files for each package! That's so terrible! You should definitely look through /usr/share, there are lots of other files you dont absolutely need too. Maybe you should start filing bugs against every package that install these tiny files you don't need! All those wasted inodes! If that's the case (they are essential for Gnome or whatever to work, just two files per package, not bringing any additional dependencies nor probability of causing compilation failures), I find it rather odd to make it optional at all. As for attempted irony of yours, I've already filled some gtk-doc and USE=doc related bugs, thxbye :P -- regards MM
Re: [gentoo-dev] RFC: Moving more developer data to LDAP, for scalability/redundancy (away, foward, permissive, SMTP password, plan) [WAS: Suggestion to ask devs to change their bugzilla name]
On Friday 11 of June 2010 09:24:45 Peter Volkov wrote: В Чтв, 10/06/2010 в 23:42 -0700, Alec Warner пишет: I don't agree with that, but just out of curiosity, is it possible to use a web interface? phpldapadmin or something The problem with phpldapadmin is that it potentially opens up LDAP to the world. Require everybody to forward connection through ssh to get ldap web interface? It's not hard to setup such tunnel manually or e.g. use xinetd for automatic tunnel creation on request... Another option is to use https with ssl client side certificates). I think it's not hard for developers to generate certificates on dev.gentoo.org and import them into browsers. I suppose simply making LDAP globally available (SSL only) is asking for trouble. In such case anyway one could choose his/her favourite LDAP client. Anyway I think simple shell scripts for most common activities (devaway, change etc) would do. I'm all for moving to LDAP every info that fits and it's possible. Maybe even things like Gentoo overlays access. -- regards MM
Re: [gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs -- xmerlin, yoswink, chtekk, omp, tantive, mueli, bluebird, hncaldwell, caleb
On Friday 11 of June 2010 21:26:06 Ben de Groot wrote: On 11 June 2010 21:12, Ben de Groot yng...@gentoo.org wrote: As I'm retiring, the following packages I maintained need someone else to look after them: media-video/avidemux - video and qt herds (this one needs a version bump) media-video/smplayer - qt and video herds x11-themes/haematite-xcursors - desktop-misc herd x11-themes/obsidian-xcursors - ,, x11-themes/pearlgrey-xcursors - ,, x11-wm/openbox - hwoarang?, lxde herd, desktop-wm herd app-misc/vifm -- this is now maintainer-needed! app-text/wgetpaste -- this is now maintainer-needed! Also, my proxy-maintainers will need new contacts: x11-wm/echinus - anyone from desktop-wm still active? dev-php/roadsend-php - anyone from php? I hope I didn't forget anything. I forgot to add: app-text/poppler - reavertm?, now assigned to kde herd, and printing herd which is basically dead Yeah, kde herd is on it. app-text/poppler-data - assigned to dead printing herd and loki_val who is on extended devaway We can also assimilate this one if needed. -- regards MM
Re: [gentoo-dev] Gentoo Council 2010/2011 - Nominations are now open
On Saturday 05 of June 2010 02:00:02 Torsten Veller wrote: Hello fellow developers and users. Nominations for the Gentoo Council 2010/2011 are now open for the next two weeks (until 23:59 UTC, 18/06/2010). All nominations must be sent to the gentoo-dev mailing list. If you were nominated and want to run, you have to accept your nomination on the same mailing list. I'd like to nominate scarabeus and betelgeuse. -- regards MM
Re: [gentoo-dev] Re: [Survey || RFC] autotools-utils.eclass
On Wednesday 26 of May 2010 19:27:43 Mike Frysinger wrote: On Wednesday 26 May 2010 05:38:00 Maciej Mrozowski wrote: I've updated documentation, added example usage and option to keep libtool files (ltdl.so supposedly needs those as I was told, no idea what for). more applicable to us w/Linux is that static linking with libtool needs them. the AUTOTOOLS_KEEP_LA_FILES seems kind of spurious considering current tree behavior and assumption of gnu-capable linking systems. It is spurious when we forget about run-time dynamic linking (plugins) in some apps. libtool loader (ltdl.so) needs .la files unfortunately. One example - imagemagick - removing .la files for coders makes 'convert' unable to locate them (silly, but hey...). Using autotools-utils for such packages would mean: - either not having static-libs in IUSE - barely acceptable - or having static-libs in IUSE but overriding all autotools-utils provided phases that make some actions depending on that USE flag - barely convenient (or not using this eclass, but like I said - I'd prefer it was able to obsolete all other autotools related eclasses - for ebuild API unification purpose - in such case it would be adopted by base-system@ most likely - hmm but then I'd need to add ''EAPI-2 support, and it means src_unpack which I want to avoid) Since .la files aren't unfortunately exclusively related to static libs, I think it's better to have a simple option to keep .la files and be able to produce static libs in straightforward way even when this option for most cases would be simply redundant. -- regards MM
Re: [gentoo-dev] Re: [Survey || RFC] autotools-utils.eclass
On Wednesday 26 of May 2010 11:12:10 Duncan wrote:
Mike Frysinger posted on Wed, 26 May 2010 00:31:21 -0400 as excerpted:
On Tuesday 25 May 2010 23:59:22 Maciej Mrozowski wrote:
On Tuesday 25 of May 2010 20:31:33 Mike Frysinger wrote:
the src_test func looks like its copying pasting stuff from the PM.
this really should be kept in the PM without duplicating it
everywhere.
Unfortunately src_test needs to be called in build dir (which is
unknown to PM).
Calling default_src_test is the best I could come up with.
should be fine
What about a one-liner explaining why it's here, so the next guy to
look at it won't be having MF's reaction all over again?
Again?
I've updated documentation, added example usage and option to keep libtool
files (ltdl.so supposedly needs those as I was told, no idea what for).
--
regards
MM
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: autotools-utils.eclass
# @MAINTAINER:
# Maciej Mrozowski reave...@gentoo.org
# @BLURB: common ebuild functions for autotools-based packages
# @DESCRIPTION:
# autotools-utils.eclass is autotools.eclass(5) and base.eclass(5) wrapper
# providing all inherited features along with econf arguments as Bash array,
# out of source build with overridable build dir location, static archives
# handling, libtool archives removal, enable/disable debug handling.
#
# @EXAMPLE:
# Typical ebuild using autotools-utils.eclass:
#
# @CODE
# EAPI=2
#
# inherit autotools-utils
#
# DESCRIPTION=Foo bar application
# HOMEPAGE=http://foo.org/;
# SRC_URI=mirror://sourceforge/foo/${P}.tar.bz2
#
# LICENSE=LGPL-2.1
# KEYWORDS=
# SLOT=0
# IUSE=debug examples qt4 static-libs tiff
#
# DEPEND=
# media-libs/libpng:0
# qt4? (
# x11-libs/qt-core:4
# x11-libs/qt-gui:4
# )
# tiff? ( media-libs/tiff:0 )
#
# RDEPEND=${DEPEND}
# !media-gfx/bar
#
#
# # bug 123456
# AUTOTOOLS_IN_SOURCE_BUILD=1
#
# DOCS=(AUTHORS ChangeLog README Read me.txt TODO)
#
# PATCHES=(
# ${FILESDIR}/${P}-gcc44.patch # bug 123458
# ${FILESDIR}/${P}-as-needed.patch
# ${FILESDIR}/${P}-unbundle_libpng.patch
# )
#
# src_configure() {
# myeconfargs=(
# $(use_with qt4)
# $(use_enable threads multithreading)
# $(use_with tiff)
# )
# autotools-utils_src_configure
# }
#
# src_install() {
# autotools-utils_src_install
# if use examples; then
# dobin ${AUTOTOOLS_BUILD_DIR}/foo_example{1,2,3} \\
# || die 'dobin examples failed'
# fi
# }
#
# @CODE
# Keep variable names synced with cmake-utils and the other way around!
case ${EAPI:-0} in
2|3|4) ;;
*) DEPEND=EAPI-TOO-OLD ;;
esac
inherit autotools base
EXPORT_FUNCTIONS src_prepare src_configure src_compile src_install src_test
# @ECLASS-VARIABLE: AUTOTOOLS_BUILD_DIR
# @DESCRIPTION:
# Build directory, location where all autotools generated files should be
# placed. For out of source builds it defaults to ${WORKDIR}/${P}_build.
# @ECLASS-VARIABLE: AUTOTOOLS_IN_SOURCE_BUILD
# @DESCRIPTION:
# Set to enable in-source build.
# @ECLASS-VARIABLE: AUTOTOOLS_KEEP_LA_FILES
# @DESCRIPTION:
# Do not remove libtool files.
# @ECLASS-VARIABLE: ECONF_SOURCE
# @DESCRIPTION:
# Specify location of autotools' configure script. By default it uses ${S}.
# @ECLASS-VARIABLE: myeconfargs
# @DESCRIPTION:
# Optional econf arguments as Bash array. Should be defined before calling
src_configure.
# @CODE
# src_configure() {
# myeconfargs=(
# --disable-readline
# --with-confdir=/etc/nasty foo confdir/
# $(use_enable debug cnddebug)
# $(use_enable threads multithreading)
# )
# autotools-utils_src_configure
# }
# @CODE
# Determine using IN or OUT source build
_check_build_dir() {
: ${ECONF_SOURCE:=${S}}
if [[ -n ${AUTOTOOLS_IN_SOURCE_BUILD} ]]; then
AUTOTOOLS_BUILD_DIR=${ECONF_SOURCE}
else
: ${AUTOTOOLS_BUILD_DIR:=${WORKDIR}/${P}_build}
fi
echo Working in BUILD_DIR: \$AUTOTOOLS_BUILD_DIR\
}
# @FUNCTION: autotools-utils_src_prepare
# @DESCRIPTION:
# The src_prepare function, supporting PATCHES array and user patches.
# See base.eclass(5) for reference.
autotools-utils_src_prepare() {
debug-print-function $FUNCNAME $@
# TODO Maybe some smart patching and automatic eautoreconf call?
base_src_prepare
}
# @FUNCTION: autotools-utils_src_configure
# @DESCRIPTION:
# The src_configure function. For out of source build it creates build
# directory and runs econf there. Configuration parameters defined
# in myeconfargs are passed here to econf. Additionally following USE
# flags are known:
#
# IUSE=debug passes --disable-debug/--enable-debug to econf respectively.
#
# IUSE=static-libs passes --enable-shared and either
--disable
[gentoo-dev] cmake-utils.eclass updated
Changes: - use DOCS and HTML_DOCS support from base.eclass (arrays), provide backward compatibility code - remove documentation of internal functions so that only relevant and public API is in manual So in short, when using cmake-utils, please from now on define DOCS and HTML_DOCS as arrays as opposite to whitespace separated string. http://sources.gentoo.org/eclass/cmake-utils.eclass?r1=1.51r2=1.52 -- regards MM
[gentoo-dev] [Survey || RFC] autotools-utils.eclass
Is anyone interested in cmake-utils like autotools/base wrapper?
Features:
- base.eclass autopatcher (including user patches)
- myeconfargs - econf arguments as Bash array (usage like mycmakeargs in
cmake-utils)
- out of source build (enabled by default) with overridable build dir location
- static archives handling (enable/disable static based on static-libs in
IUSE)
- libtool archives removal (depending on static-libs USE flag)
- enable/disable debug handling (debug in IUSE)
- cmake-utils resemblance (DOCS, HTML_DOCS variables)
- ???
- Profit! ;)
Example usage in attached clucene-0.9.21b-r1.
Also a patch for base.eclass to make it's econf accept arguments + some random
function documentation fix.
--
regards
MM
Index: base.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/base.eclass,v
retrieving revision 1.50
diff -u -B -r1.50 base.eclass
--- base.eclass 12 Apr 2010 15:33:03 - 1.50
+++ base.eclass 25 May 2010 10:46:31 -
@@ -65,7 +65,7 @@
# @FUNCTION: base_src_prepare
# @DESCRIPTION:
# The base src_prepare function, which is exported
-# EAPI is greater or equal to 2.
+# EAPI is greater or equal to 2. Here the PATCHES array is evaluated.
base_src_prepare() {
debug-print-function $FUNCNAME $@
debug-print $FUNCNAME: PATCHES=$PATCHES
@@ -116,13 +116,12 @@
# @FUNCTION: base_src_configure
# @DESCRIPTION:
# The base src_configure function, which is exported when
-# EAPI is greater or equal to 2. Runs basic econf. Here the PATCHES array is
-# evaluated.
+# EAPI is greater or equal to 2. Runs basic econf.
base_src_configure() {
debug-print-function $FUNCNAME $@
# there is no pushd ${S} so we can override its place where to run
- [[ -x ${ECONF_SOURCE:-.}/configure ]] econf
+ [[ -x ${ECONF_SOURCE:-.}/configure ]] econf $@
}
# @FUNCTION: base_src_compile
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: autotools-utils.eclass
# @MAINTAINER:
# reave...@gentoo.org
# @DESCRIPTION:
# autotools.eclass and base.eclass wrapper providing following features:
# - autopatcher (including user patches)
# - myeconfargs - econf arguments as Bash array
# - out of source build (enabled by default) with overridable build dir location
# - static archives handling (static-libs in IUSE)
# - libtool archives removal (depending on static-libs USE flag)
# - enable/disable debug handling (debug in IUSE)
# - cmake-utils resemblance (DOCS, HTML_DOCS variables)
# Keep variable names synced with cmake-utils!
case ${EAPI:-0} in
2|3|4) ;;
*) DEPEND=EAPI-TOO-OLD ;;
esac
inherit autotools base
EXPORT_FUNCTIONS src_prepare src_configure src_compile src_install src_test
# @ECLASS-VARIABLE: AUTOTOOLS_IN_SOURCE_BUILD
# @DESCRIPTION:
# Set to enable in-source build.
# @FUNCTION: _check_build_dir
# @DESCRIPTION:
# Determine using IN or OUT source build
_check_build_dir() {
# @ECLASS-VARIABLE: ECONF_SOURCE
# @DESCRIPTION:
# Sets the directory where we are working with autotools.
# By default it uses ${S}.
: ${ECONF_SOURCE:=${S}}
# @ECLASS-VARIABLE: AUTOTOOLS_BUILD_DIR
# @DESCRIPTION:
# Specify the build directory where all autotools generated
# files should be located.
# For installing binary doins ${AUTOTOOLS_BUILD_DIR}/somefile
if [[ -n ${AUTOTOOLS_IN_SOURCE_BUILD} ]]; then
# we build in source dir
AUTOTOOLS_BUILD_DIR=${ECONF_SOURCE}
else
: ${AUTOTOOLS_BUILD_DIR:=${WORKDIR}/${P}_build}
fi
echo Working in BUILD_DIR: \$AUTOTOOLS_BUILD_DIR\
}
# @FUNCTION: autotools-utils_src_prepare
# @DESCRIPTION:
# The src_prepare function, which is exported EAPI is greater or equal to 2.
autotools-utils_src_prepare() {
debug-print-function $FUNCNAME $@
# TODO Maybe some smart patching and automatic eautoreconf call?
base_src_prepare
}
# @FUNCTION: autotools-utils_src_configure
# @DESCRIPTION:
# The src_configure function, which is exported when EAPI is greater or equal
# to 2. Runs basic econf. Here the PATCHES array is evaluated.
autotools-utils_src_configure() {
debug-print-function $FUNCNAME $@
# @ECLASS-VARIABLE: myeconfargs
# @DESCRIPTION:
# econf arguments as Bash array, enable shared libs by default
local econfargs=(
--enable-shared
${myeconfar...@]}
)
# Handle debug found in IUSE
if has debug ${IUSE//+}; then
econfargs+=($(use_enable debug))
fi
# Handle static-libs found in IUSE, disable them by default
if has static-libs ${IUSE//+}; then
econfargs+=($(use_enable static-libs static))
else
econfargs+=(--disable-static)
fi
_check_build_dir
mkdir -p ${AUTOTOOLS_BUILD_DIR} ||
[gentoo-dev] Re: [Survey || RFC] autotools-utils.eclass
On Tuesday 25 of May 2010 13:02:55 Maciej Mrozowski wrote: Also a patch for base.eclass to make it's econf accept arguments + some random function documentation fix. Commited mentioned base.eclass patch + added quoting of positional parameter expansion. http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo- x86/eclass/base.eclass?r1=1.50r2=1.52 -- regards MM
Re: [gentoo-dev] [Survey || RFC] autotools-utils.eclass
On Tuesday 25 of May 2010 20:31:33 Mike Frysinger wrote: internal functions should not be documented with the eclass doc comments (_check_build_dir) Fixed. reusing a PM variable (ECONF_SOURCE) seems a little iffy I know, initial idea was to use AUTOTOOLS_USE_DIR (analogy to CMAKE_USE_DIR), but then I discovered that I'd need to set ECONF_SOURCE anyway. So to avoid duplicating variables, I opted for ECONF_SOURCE reuse. If it's supposed to have internal meaning and is not part of public API, then I agree should not be used. I see it's explicitly mentioned in PMS though. Waiting for further comments on that matter. the library handling is incorrect. i dont think you can pass around --enable- shared all the time without having configure generate warnings about unknown options. default to --disable-static when static-libs doesnt exist is wrong -- that's the opposite of what you should be doing. ignoring the same issue as the share option i mentioned above. Right. It its safe to assume that when --disable-static/--enable-static is available, then --disable-shared/--enable-shared is available as well? pushd/popd should have stdout sent to /dev/null, not stderr too Fixed. the src_install func has the static-libs checks in the incorrect order Fixed. the src_test func looks like its copying pasting stuff from the PM. this really should be kept in the PM without duplicating it everywhere. Unfortunately src_test needs to be called in build dir (which is unknown to PM). Calling default_src_test is the best I could come up with. But what's the most important - is there any interest in having such eclass? I'm only going to add it when it's flexible enough to effectively phase-out eutils/base/autotools/libtool individual uses for fully autotools-controlled buildsystems. Otherwise there's no point in yet another wrapper imho. I was also thinking of integrating parts of src_prepare from virtuoso.eclass into autotools-utils.eclass - it provides basic support for package splitting of well formed (TM) and clean autotools build systems. (example packages are virtuoso-odbc and virtuoso-server). Thanks -- regards MM
Re: [gentoo-dev] [Survey || RFC] autotools-utils.eclass
Bummer...
Forgot to attach file in question.
--
regards
MM
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: autotools-utils.eclass
# @MAINTAINER:
# reave...@gentoo.org
# @DESCRIPTION:
# autotools.eclass and base.eclass wrapper providing all inherited features
along with:
# - myeconfargs - econf arguments as Bash array
# - out of source build (enabled by default) with overridable build dir location
# - static archives handling (static-libs in IUSE)
# - libtool archives removal (depending on static-libs USE flag)
# - enable/disable debug handling (debug in IUSE)
# Keep variable names synced with cmake-utils and the other way around!
case ${EAPI:-0} in
2|3|4) ;;
*) DEPEND=EAPI-TOO-OLD ;;
esac
inherit autotools base
EXPORT_FUNCTIONS src_prepare src_configure src_compile src_install src_test
# Determine using IN or OUT source build
_check_build_dir() {
# @ECLASS-VARIABLE: ECONF_SOURCE
# @DESCRIPTION:
# Sets the directory where we are working with autotools.
# By default it uses ${S}.
: ${ECONF_SOURCE:=${S}}
# @ECLASS-VARIABLE: AUTOTOOLS_IN_SOURCE_BUILD
# @DESCRIPTION:
# Set to enable in-source build.
if [[ -n ${AUTOTOOLS_IN_SOURCE_BUILD} ]]; then
# @ECLASS-VARIABLE: AUTOTOOLS_BUILD_DIR
# @DESCRIPTION:
# Specify the build directory where all autotools generated
# files should be located.
# For installing binary doins ${AUTOTOOLS_BUILD_DIR}/somefile
AUTOTOOLS_BUILD_DIR=${ECONF_SOURCE}
else
: ${AUTOTOOLS_BUILD_DIR:=${WORKDIR}/${P}_build}
fi
echo Working in BUILD_DIR: \$AUTOTOOLS_BUILD_DIR\
}
# @FUNCTION: autotools-utils_src_prepare
# @DESCRIPTION:
# The src_prepare function, which is exported EAPI is greater or equal to 2.
autotools-utils_src_prepare() {
debug-print-function $FUNCNAME $@
# TODO Maybe some smart patching and automatic eautoreconf call?
base_src_prepare
}
# @FUNCTION: autotools-utils_src_configure
# @DESCRIPTION:
# The src_configure function, which is exported when EAPI is greater or equal
# to 2. Runs basic econf. Here the PATCHES array is evaluated.
autotools-utils_src_configure() {
debug-print-function $FUNCNAME $@
# @ECLASS-VARIABLE: myeconfargs
# @DESCRIPTION:
# econf arguments as Bash array
local econfargs=(
${myeconfar...@]}
)
# Handle debug found in IUSE
if has debug ${IUSE//+}; then
econfargs+=($(use_enable debug))
fi
# Handle static-libs found in IUSE, disable them by default
if has static-libs ${IUSE//+}; then
econfargs+=(
--enable-shared
$(use_enable static-libs static)
)
fi
_check_build_dir
mkdir -p ${AUTOTOOLS_BUILD_DIR} || die mkdir
'${AUTOTOOLS_BUILD_DIR}' failed
pushd ${AUTOTOOLS_BUILD_DIR} /dev/null
base_src_configure ${econfar...@]}
popd /dev/null
}
# @FUNCTION: autotools-utils_src_compile
# @DESCRIPTION:
# The autotools src_compile function, calls src_configure with EAPI older
# than 2.
autotools-utils_src_compile() {
debug-print-function $FUNCNAME $@
_check_build_dir
pushd ${AUTOTOOLS_BUILD_DIR} /dev/null
base_src_compile $@
popd /dev/null
}
# @FUNCTION: autotools-utils_src_install
# @DESCRIPTION:
# The autotools src_install function. Runs make install and removes libtool
files.
autotools-utils_src_install() {
debug-print-function $FUNCNAME $@
_check_build_dir
pushd ${AUTOTOOLS_BUILD_DIR} /dev/null
base_src_install
popd /dev/null
# Remove libtool archives
if has static-libs ${IUSE//+} ! use static-libs; then
find ${D} -type f -name '*.la' -exec rm -f {} + \
|| die 'libtool archive removal failed'
fi
}
# @FUNCTION: autotools-utils_src_test
# @DESCRIPTION:
# The autotools src_test function. Runs emake check in source directory.
autotools-utils_src_test() {
debug-print-function ${FUNCNAME} $@
_check_build_dir
pushd ${AUTOTOOLS_BUILD_DIR} /dev/null
default_src_test
popd /dev/null
}
Re: [gentoo-dev] Re: [RFC] Gentoo Wiki Project
On Friday 09 of April 2010 13:26:16 Guy Fontaine wrote: There are things I know about Gentoo Linux and I'm pleased to share my knowledge with others as well as I'm glad to learn from others. I'm not a Gentoo dev and I neither have plan nor wish to be. My feeling is that Gentoo Wiki Project is just but another occasion for debating rules and politics. Reading some messages from some people I feel like I'm not welcome because I'm not a member of a group of selected people. I have a French wiki to maintain, Gentoo-Québec's one, and I also have to help people by answering their questions on Gentoo-Québec forum. I think my real place is there. See? This is the problem. Every time comes an initiative to introduce official Gentoo infra hosted Gentoo Wiki (yes, the one that won't loose randomly all its contents) - there's lack of interest of cooperation from already existing unofficial Gentoo-related Wiki admins. And of course it's always Gentoo devs who are to blame for creating duplicated effort instead of normalizing current situation. Btw, you should only care for opinion of Gentoo Wiki project members, which are listed there - http://www.gentoo.org/proj/en/wiki/ cheers -- regards MM
Re: [gentoo-dev] [git migration] Proposition for tags supported by git hooks
On Tuesday 06 of April 2010 04:13:02 Nirbheek Chauhan wrote: One of the few remaining problems to be solved for the migration to git for our gentoo-x86/ and gentoo/ trees (besides other projects/overlays) is the problem of how to handle ChangeLogs. Great that you touched this topic. Problems: * Messages in ChangeLog are not always the same as the commit messages (~1% are different) * Some people place additional information in the commit message which is intended only for developer use - Most of the difference in ChangeLog/commit messages comes from this * Trivial changes are often not documented in ChangeLogs - This is upto the developer's personal preference - Some folks do this because of the extra time it takes + This use-case becomes irrelevant due to automatic generation of ChangeLog Solutions: * Do not re-generate the existing ChangeLog; rather make the ChangeLog generation script smart enough to only append - Solves the messages not same problem for existing commits I don't think its' good idea, changelog should reflect state of remote repository, not the state of local clone. Besides storing Changelog is simply redundant and would increase repository size unnecessarily. It already increases rsync size considerably. * Use a separator in the commit message like == \n to denote that everything after this is dev-only information and should be skipped from the user ChangeLog - Solves the problem for people who like to add extra dev-only info in the CVS commit message * Ignore commits with [$tag][trivial] in the tag[2] from being added to ChangeLog - Keeps the wishes of the developer and does not pollute ChangeLog with such info Both would work fine, maybe tag syntax could be improved - certainly we want it error prone and relatively simple to use - I've moved it to separate subthread. Maybe something like this: (modeled a bit after KDE tags allowed in svn messages): Each entry in its own line in commit message: BUG: bugnumber Marks the bug as RESO/FIXED, as comment adding full git commit message with tags removed and just below gitweb URL corresponding to this particular commit. For bugzilla, instead of full gitweb URL, maybe make bugzilla aware of hashes in comments and expand gitweb links automatically CCBUG: bugnumber Adds comment to the bugreport containing full git commit message with tags removed and just below gitweb URL corresponding to this particular commit. For bugzilla, instead of full gitweb URL, maybe make bugzilla aware of hashes in comments and expand gitweb links automatically CCMAIL: one-email-address Sends email to given address containing full git commit message with tags removed and just below gitweb URL corresponding to this particular commit SILENT: Marks entire commit message as silent by adding (silent) to the subject of the mail or adding some mail header to allow filtering out trivial commits. (like those containing typo fixes in comments and such). Such commits could also be skipped by ChangeLog generator. I specifically don't like [tag][sth] format, because I'd suggest to impose some guidelines to git commit messages: - put [$CATEGORY/$PN] in first line of commit message for git commits related to packages - same with [$profile] for profiles or [package.mask] for p.mask, [eclass/$ECLASS] etc to make history a bit more readable, see example: http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=summary Also some number (for instance up to 80) of characters from first line could be used as email Subject in CCMAIL, so I think it's vital to have it organized a bit. -- regards MM
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
On Tuesday 06 of April 2010 07:47:17 Rémi Cardona wrote: How about changing how users search instead? Let's make the small search box search for ALL bugs instead of just opened ones. *That* should help tremendously. +1, maybe even enable it by default. That could reduce dupes imho. That, and what Mart suggested. That's a good idea too. -1 As for me, RESOLVED/LATER is sth like in v2.0, so maybe I'll waste my time to fix it in a future but I don't really bother and I don't see it happening tbh so don't bug me anymore. Unresolved valid issues should stay open, that's my reasoning. -- regards MM
Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries
On Sunday 04 of April 2010 17:33:17 Tiziano Müller wrote: Besides I can already imagine PMS-related discussion regarding make the PMs check for rdeps per default before unmerging things - thx but no thx. This is not related to PMS. Paludis for example does it already with the current EAPIs. So how does Paludis handle those issues? (Read my comments about emerge atomicy below) It is a problem which can _only_ be solved at the PM level. You have to tell the PM when API breakages happen. Either by slotting the lib or by something else. ^^^ This is important - as slotting is not a practical solution. What is it then? Using guesswork to determine whether or not a library should be removed may be a temporary solution. Remember: you're partially ignoring a users request since he wanted the package to be removed - and we all know how things like protect the user from himself end up. Unconditionally removing libraries (instead of preserving them) and making their reverse runtime dependencies reinstalled is unacceptable because emerge process involving multiple packages is not atomic. Simple as that. Is this what you suggest? Correct me if I'm wrong: 1. Users wants to uninstall or reinstall package, we let him do it provided reverse runtime dependencies are satisfied afterwards. Let's say he wants to upgrade expat. 2. Expat SOVERSION changed meanwhile but package was not SLOTtted and runtime reverse deps will still be satisfied when we upgrade. 3. Expat has been upgraded sucessfully, 4a. emerge discovers reverse runtime dependencies are broken and it starts to rebuild them, then it bails out due to error ld: libexpat.so.sth not found. Because step 3 cannot be rolled back (no atomicy) - game over. or 4b. emerge does not discover those and does nothing. python is broken so emerge cannot be used anymore. Game over -- regards MM
[gentoo-dev] [RFC] More reliable hiding preserved libraries
Problem
..is known, let me summarize briefly.
Uninstalling packages providing libraries, without checking reverse runtime
dependencies of those packages leaves their dependencies unsatisfied (packages
with broken executables and/or shared libs).
Some package managers try their best not to remove said libraries, yet
allowing packages to be removed.
Those orphaned libraries cause problems[1] as build systems of some other
packages being (re)installed afterwards pick them up and abuse those orphaned
libraries. (we don't like orphans abused, we prefer them... gone).
Solution
Now, I suppose there are some ideas how to make orphaned libraries not go in a
way. Basically then need to be available for system, but hidden for emerge.
There is opt-out suggestion[2], unfortunately it does not provide any info how
exactly it's supposed to be achieved. As far as portage/pkgcore is concerned,
maybe - as Brian Harring suggested - sandbox could be used to somehow hide
preserved libraries or preserved library directory from ebuild environment
(preserved library directory a'ka purgatory - libs could be moved there when
considered orphaned).
Opt-in suggestion is as follows:
1. Use some library path (read by ld loader from environment) and export it
globally to environment pointing it to preserved library directory.
2. During emerge, unset environment variable corresponding to said preserved
library directory - orphans are no longer located.
Attached patch for glibc (2.11, but should apply to any other glibc around)
and uClibc (this one is not tested but should work as well) that makes ld
loader aware of LD_GENTOO_PRESERVED_LIBRARY_PATH variable.
(LD_LIBRARY_PATH would work as well, but it's being used widely so cannot be
safely mangled.. on the second though it can - one could filter out preserved
library paths from it during emerge).
Thoughts?
1. https://bugs.gentoo.org/show_bug.cgi?id=240323
2. https://bugs.gentoo.org/show_bug.cgi?id=307391
--
regards
MM
diff -ru ../glibc-2.11/elf/rtld.c ./elf/rtld.c
--- ../glibc-2.11/elf/rtld.c 2009-10-30 18:17:08.0 +0100
+++ ./elf/rtld.c 2010-04-03 10:51:46.468906521 +0200
@@ -874,6 +874,8 @@
/* The library search path. */
static const char *library_path attribute_relro;
+/* Gentoo preserved library path. */
+static const char *preserved_library_path attribute_relro;
/* The list preloaded objects. */
static const char *preloadlist attribute_relro;
/* Nonzero if information about versions has to be printed. */
@@ -1385,7 +1387,18 @@
/* Initialize the data structures for the search paths for shared
objects. */
- _dl_init_paths (library_path);
+ char *llp = alloca ((library_path != NULL ? strlen (library_path) : 0) +
+(preserved_library_path != NULL ? strlen (preserved_library_path) : 0) + 2);
+ *llp = '\0';
+ if (library_path != NULL)
+{
+ strcat (llp, library_path);
+ if (preserved_library_path != NULL)
+strcat (llp, :);
+}
+ if (preserved_library_path != NULL)
+strcat (llp, preserved_library_path);
+ _dl_init_paths (llp);
/* Initialize _r_debug. */
struct r_debug *r = _dl_debug_initialize (GL(dl_rtld_map).l_addr,
@@ -2648,6 +2661,16 @@
mode = trace;
break;
+ case 29:
+ /* Read Gentoo preserved library path from env here. Watch out for
+ possible future 'case' additions in this switch as well as in
+ EXTRA_LD_ENVVARS defined in sysdeps/arch/dl-librecon.h.
+ LD_GENTOO_PRESERVED_LIBRARY_PATH is blacklisted for SUID
+ programs in sysdeps/generic/unsecvars.h. */
+ if (memcmp (envline, GENTOO_PRESERVED_LIBRARY_PATH, 29) == 0)
+ preserved_library_path = envline[30];
+ break;
+
/* We might have some extra environment variable to handle. This
is tricky due to the pre-processing of the length of the name
in the switch statement here. The code here assumes that added
diff -ru ../glibc-2.11/sysdeps/generic/unsecvars.h ./sysdeps/generic/unsecvars.h
--- ../glibc-2.11/sysdeps/generic/unsecvars.h 2009-10-30 18:17:08.0 +0100
+++ ./sysdeps/generic/unsecvars.h 2010-04-03 10:48:07.192280437 +0200
@@ -10,6 +10,7 @@
LD_DEBUG_OUTPUT\0 \
LD_DYNAMIC_WEAK\0 \
LD_LIBRARY_PATH\0 \
+ LD_GENTOO_PRESERVED_LIBRARY_PATH\0 \
LD_ORIGIN_PATH\0 \
LD_PRELOAD\0 \
LD_PROFILE\0 \
diff -ru ../uClibc-0.9.30.1/ldso/include/dl-hash.h ./ldso/include/dl-hash.h
--- ../uClibc-0.9.30.1/ldso/include/dl-hash.h 2008-11-03 16:41:17.0 +0100
+++ ./ldso/include/dl-hash.h 2010-04-03 11:23:44.026291507 +0200
@@ -132,6 +132,7 @@
extern int _dl_linux_dynamic_link(void);
extern char * _dl_library_path;
+extern char * preserved_library_path;
extern char * _dl_not_lazy;
static __inline__ int _dl_symbol(char * name)
diff -ru ../uClibc-0.9.30.1/ldso/include/ldso.h ./ldso/include/ldso.h
--- ../uClibc-0.9.30.1/ldso/include/ldso.h 2008-05-30 16:35:31.0 +0200
Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries
On Saturday 03 of April 2010 12:56:04 Fabian Groffen wrote: Is it known why this does happen exactly? When a lib is kept because it is still used, only its soname + what the soname points to should be kept. That would mean the lib can no longer be found during linking, unless you add some trickery (or does GNU ld do something handy out of the box right here?). So for example: % ls usr/lib/libfoo.so - libfoo.so.2.1 usr/lib/libfoo.so.2 - libfoo.so.2.1 usr/lib/libfoo.so.2.1 % scanelf --soname usr/lib/libfoo.so libfoo.so.2 usr/lib/libfoo.so what should kept preserved is: usr/lib/libfoo.so.2 - libfoo.so.2.1 usr/lib/libfoo.so.2.1 because trying to link to libfoo using `gcc -o bar -lfoo bar.c` should (in theory and on some platforms at least) fail. It doesn't matter, as 'broken' build system may alphabetically find library by file name, and link to this library by full path. On Saturday 03 of April 2010 13:13:00 Michał Górny wrote: 2. During emerge, unset environment variable corresponding to said preserved library directory - orphans are no longer located. Wouldn't that cause failure when the toolkit relies on a 'hidden' preserved library? It would indeed. Now when I think about it, moving stuff to preserved library dir could be just done - provided it's possible - along with fixing/setting DT_RPATH's in reverse runtime dependencies. This way no system-wide LIBRARY_PATH's would be necessary. Is it possible? Mike? On Saturday 03 of April 2010 13:33:16 Gilles Dartiguelongue wrote: There is opt-out suggestion[2], unfortunately it does not provide any info how exactly it's supposed to be achieved. As far as portage/pkgcore is concerned, maybe - as Brian Harring suggested - sandbox could be used to somehow hide preserved libraries or preserved library directory from ebuild environment (preserved library directory a'ka purgatory - libs could be moved there when considered orphaned). that sounds nice, it would allow us to more easily spot packages/upstreams doing it wrong (maybe that would work for packages linking to themselves too btw) Keeping preserved libraries in separate location (in purgatory or dumping place) is just a method for making implementation possibly easier (or possible at all), with nice side effects though. -- regards MM
Re: [gentoo-dev] [RFC] More reliable hiding preserved libraries
On Saturday 03 of April 2010 14:16:14 Fabian Groffen wrote: Shouldn't we fix that buildsystem then? Do you have an example of a package/buildsystem that does that? We already do, the thing is that maybe we don't have to. https://bugs.gentoo.org/show_bug.cgi?id=240323 From top of my head: python having issues with sys-libs/db as well as some packages with readline. It would indeed. Now when I think about it, moving stuff to preserved library dir could be just done - provided it's possible - along with fixing/setting DT_RPATH's in reverse runtime dependencies. This way no system-wide LIBRARY_PATH's would be necessary. Is it possible? Mike? No, unless you somehow make sure you reserve space for this, by e.g. setting a bogus rpath entry at buildtime. If you want to go that route, you probably want to look at the Prefix' binutils-config wrapper that already calls the linker with added rpath arguments. Afterwards you can use chrpath to set it to the correct location. Will get messy with the vdb though, but if Portage's doing it, it can probably be dealt with. Sounds messy indeed, what about hardened/SELinux/AppArmor/whatever - do they allow such DT_RPATH operations? It should be probably also restricted for binary-only packages. On Saturday 03 of April 2010 20:51:43 Tiziano Müller wrote: Don't fix the hack. Remove the preserve libs feature, make the PMs check for rdeps per default before unmerging things. This will only prevent creating orphans of uninstalled libraries, what about upgraded ones when SOVERSION has been bumped (the most common case)? Besides I can already imagine PMS-related discussion regarding make the PMs check for rdeps per default before unmerging things - thx but no thx. Slot libraries where needed, slot dep operators (EAPI 4) will help. Again, you suggest to SLOT every library that happened to bump SOVERSION. It's unrealistic. Besides library should be slotted when it's API changes, for source based distributions it's not needed for ABI changes - let's not confuse those two. Also excessive slotting increases probability of breaking library discovery mechanisms in various build systems (not everyone uses pkg-config). And if that doesn't work out we need a separate var to give the PM a hint when API/ABI breakages happen (such that the PM knows when to re-install the rev deps). It needs PMS amended and thus GLEP. Please submit a GLEP item for this if you see it fit. Anyway, as explained in OT, it's not a problem of package manager dependencies system but issue with broken/not smart build systems - no dependency tree magic will solve this issue. -- regards MM
Re: [gentoo-dev] [RFC] Reworking package stabilization policies
On Monday 29 of March 2010 09:30:38 Peter Volkov wrote: В Вск, 28/03/2010 в 07:47 +0200, Maciej Mrozowski пишет: No, seriously - given the fact that some of my packages were even stabilized without contacting me (app-misc/hal-cups-utils, app-admin/system-config- printer-common) If you know packages are broken why they were not hardmasked? If they have no problems what why it was bad idea to mark them stable? They are not broken, they're just not suitable. It's like stabilizing gcc-2.95 now, even when it won't work with some recent KDE/boost. hal-cups-utils is not a problem system-config-printer-common-1.1.13 is as it's being used by maybe incompatible now system-config-printer-kde from testing arch (I've raised those deps now), besides I wanted to wait for polkit-1 with this package (otherwise dbus newprinternotifications can be received only by root or require tweaking dbus conf to work out of the box . That's why kde- base/system-config-printer-kde and kde-base/printer-applet were intentionally left out from KDE-4.3.3 stabilization list. -- regards MM
Re: [gentoo-dev] [RFC] Reworking package stabilization policies
On Sunday 28 of March 2010 09:39:18 Ciaran McCreesh wrote: It's really freaking silly to wait months for stabilization of some random php/perl library that's known to work. How do you know it works if you don't test on the arch in question? The problem is not waiting for some instert some exotic arch here to go stable so it would be possible to close bug and ignore arches. It's not about closing bug at all. The only inconvenience from exotic arches lagging is inability to remove particular old ebuild from tree, that's it. It's about having package marked stabled on my arch (amd64 in my case, may be other from other developer's perspective) in a timely manner. And I know it works on my arch because I test it and often use it on daily basis. On Sunday 28 of March 2010 13:32:59 Richard Freeman wrote: amd64 has had the policy that any dev can stabilize if they've tested it on a stable amd64 system, and this hasn't really caused problems. That would have certainly solved the problem if that policy was written and published anywhere. -- regards MM
Re: [gentoo-dev] [RFC] Reworking package stabilization policies
On Saturday 27 of March 2010 21:58:41 William Hubbs wrote: On Sat, Mar 27, 2010 at 05:45:51PM +0100, Torsten Veller wrote: * Petteri R?ty betelge...@gentoo.org: So let's summarize for assigning to the single arch: In support (and my comments in support): - Can be used as a gentle reminder for slacker arches And if not only one arch or single arch is slacking? I guess you would find another gentle way to remind them. How about a tool generating mails to arch teams, which lists all STABLEREQ, KEQWORDREQ bugs to which the arch team is CC'ed for a month? (Or probably easier or possible at all: which weren't changed for 30 days.) I know that I have several bugs right now with minor arch's on them waiting to be stabilized. A couple have been waiting for a very long time. I have even pinged some of the bugs several times with no response. Is there anything else I can do to get these arch teams attention? Yes, I think getting from them the privilege of being the only ones able to stabilize applications should do the job. No, seriously - given the fact that some of my packages were even stabilized without contacting me (app-misc/hal-cups-utils, app-admin/system-config- printer-common) - I think it should be: * solely up to the package maintainers to stabilize application on arches they're using or on any arch if package is arch-agnostic (optionally, but preferably with some peer review from other project members or arch team members). * to arch team members in other cases (like now) * other rules (30 days 'waiting' period, bugzilla bug with STABLEREQ) applied as they are now Role of arch teams would be decreased to peer review and solving KEYWORD requests. It's really freaking silly to wait months for stabilization of some random php/perl library that's known to work. Comments? -- regards MM
Re: [gentoo-dev] Qt3 mask breaks significant science packages
On Sunday 14 of March 2010 06:09:44 James Cloos wrote: BdG == Ben de Groot yng...@gentoo.org writes: BdG Abandoned packages do not belong in the portage tree. Nonsense. That attitude only servers to harm the user base. Leaving them in does not. But leaving them broken and unmaintained in main repository harms Gentoo quality and image. User base is welcome to step up and help with maintenance and that's what guys in kde-sunsite overlay actually do. So... patches welcome! Thanks! -- regards MM
Re: [gentoo-dev] Qt3 mask breaks significant science packages
On Friday 12 of March 2010 17:17:01 Fabian Groffen wrote: On 12-03-2010 08:46:34 -0700, Denis Dupeyron wrote: That said they were perfectly entitled to make the decision of not wanting to maintain qt3 any longer. The only advice I can give is that all disgruntled users and developers create a qt3 project and adopt/unmask/re-commit the qt3 libraries for maintainers of packages who need it. I doubt this will happen as this could have been done a long time ago, but it's never too late. Didn't we have a graveyard thing/overlay somewhere some day? Some users might happily prefer to use stuff that's treecleaned, or removed due security issues. If removal of stuff would mean it's dumped in there it can be easily used by users and more easily readded later afterwards, if need arises. Yes, it's called kde-sunset and it contains KDE3 and should contain Qt3 applications (maybe it does, may not all of them though) removed from tree recently. It's not graveyard really as some users actively maintain this overlay. http://git.overlays.gentoo.org/gitweb/?p=proj/kde-sunset.git (layman -a kde-sunset) -- regards MM
