Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

2017-02-06 Thread Maciej Mrozowski
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

2016-11-04 Thread Maciej Mrozowski
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

2016-11-03 Thread Maciej Mrozowski
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

2016-11-02 Thread Maciej Mrozowski
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

2016-11-02 Thread Maciej Mrozowski
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

2016-11-02 Thread Maciej Mrozowski
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

2016-11-02 Thread Maciej Mrozowski
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

2016-05-18 Thread Maciej Mrozowski
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

2016-05-17 Thread Maciej Mrozowski
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

2016-05-02 Thread Maciej Mrozowski
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

2016-05-02 Thread Maciej Mrozowski
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

2016-05-02 Thread Maciej Mrozowski
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

2016-05-02 Thread Maciej Mrozowski
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

2015-09-16 Thread Maciej Mrozowski
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

2015-08-03 Thread Maciej Mrozowski
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

2015-06-29 Thread Maciej Mrozowski
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

2015-04-05 Thread Maciej Mrozowski
# 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

2014-03-28 Thread Maciej Mrozowski
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

2014-03-28 Thread Maciej Mrozowski
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

2014-01-17 Thread Maciej Mrozowski
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?

2013-12-15 Thread Maciej Mrozowski
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?

2013-11-24 Thread Maciej Mrozowski
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

2013-08-15 Thread Maciej Mrozowski
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()

2013-02-26 Thread Maciej Mrozowski
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

2013-02-08 Thread Maciej Mrozowski
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.

2013-02-07 Thread Maciej Mrozowski
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

2013-01-29 Thread Maciej Mrozowski
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

2012-09-21 Thread Maciej Mrozowski
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

2012-09-03 Thread Maciej Mrozowski
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)

2012-05-17 Thread Maciej Mrozowski
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?

2012-03-15 Thread Maciej Mrozowski
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

2012-01-11 Thread Maciej Mrozowski
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

2011-12-27 Thread Maciej Mrozowski
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

2011-12-20 Thread Maciej Mrozowski
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

2011-11-23 Thread Maciej Mrozowski
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

2011-11-05 Thread Maciej Mrozowski
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

2011-08-23 Thread Maciej Mrozowski
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

2011-08-16 Thread Maciej Mrozowski
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

2011-08-08 Thread Maciej Mrozowski
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?

2011-06-28 Thread Maciej Mrozowski
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?

2011-06-27 Thread Maciej Mrozowski
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?

2011-06-26 Thread Maciej Mrozowski
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

2011-06-26 Thread Maciej Mrozowski
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

2011-06-25 Thread Maciej Mrozowski
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

2011-06-25 Thread Maciej Mrozowski
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

2011-06-25 Thread Maciej Mrozowski
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

2011-06-25 Thread Maciej Mrozowski
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

2011-06-13 Thread Maciej Mrozowski
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

2011-06-12 Thread Maciej Mrozowski
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

2011-05-08 Thread Maciej Mrozowski
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

2011-05-06 Thread Maciej Mrozowski
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]

2011-05-01 Thread Maciej Mrozowski
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

2011-04-30 Thread Maciej Mrozowski
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

2011-04-27 Thread Maciej Mrozowski
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

2011-04-27 Thread Maciej Mrozowski
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

2011-01-28 Thread Maciej Mrozowski
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

2010-12-17 Thread Maciej Mrozowski
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

2010-11-25 Thread Maciej Mrozowski
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?

2010-09-17 Thread Maciej Mrozowski
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?

2010-09-17 Thread Maciej Mrozowski
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

2010-09-11 Thread Maciej Mrozowski
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

2010-09-11 Thread Maciej Mrozowski
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

2010-08-24 Thread Maciej Mrozowski
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

2010-08-23 Thread Maciej Mrozowski
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

2010-08-22 Thread Maciej Mrozowski
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)

2010-08-15 Thread Maciej Mrozowski
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

2010-08-10 Thread Maciej Mrozowski
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)

2010-07-27 Thread Maciej Mrozowski
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

2010-07-23 Thread Maciej Mrozowski
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

2010-07-19 Thread Maciej Mrozowski
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

2010-07-17 Thread Maciej Mrozowski
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

2010-07-17 Thread Maciej Mrozowski
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

2010-07-15 Thread Maciej Mrozowski
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

2010-07-15 Thread Maciej Mrozowski
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

2010-07-13 Thread Maciej Mrozowski
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

2010-07-06 Thread Maciej Mrozowski
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

2010-06-21 Thread Maciej Mrozowski
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

2010-06-21 Thread Maciej Mrozowski
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]

2010-06-11 Thread Maciej Mrozowski
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

2010-06-11 Thread Maciej Mrozowski
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

2010-06-05 Thread Maciej Mrozowski
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

2010-05-31 Thread Maciej Mrozowski
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

2010-05-26 Thread Maciej Mrozowski
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

2010-05-26 Thread Maciej Mrozowski
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

2010-05-25 Thread Maciej Mrozowski
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

2010-05-25 Thread Maciej Mrozowski
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

2010-05-25 Thread Maciej Mrozowski
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

2010-05-25 Thread Maciej Mrozowski
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

2010-04-09 Thread Maciej Mrozowski
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

2010-04-06 Thread Maciej Mrozowski
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?

2010-04-06 Thread Maciej Mrozowski
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

2010-04-05 Thread Maciej Mrozowski
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

2010-04-03 Thread Maciej Mrozowski
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

2010-04-03 Thread Maciej Mrozowski
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

2010-04-03 Thread Maciej Mrozowski
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

2010-03-29 Thread Maciej Mrozowski
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

2010-03-28 Thread Maciej Mrozowski
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

2010-03-27 Thread Maciej Mrozowski
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

2010-03-13 Thread Maciej Mrozowski
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

2010-03-12 Thread Maciej Mrozowski
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



  1   2   >