[gentoo-dev] New license - adobe-pcfi
Hi, I'm querying this list out of the need of adding a new license[1] for adobe-pcfi[2]. Suggested name for the license is adobe-pcfi. An other possibility could be Adobe-PCFI to better match other Adobe* licenses. The license would be added to the MISC-FREE license group. If you have any doubts let me know before I proceed in about a week. Thanks to ssuominen and robbat2 for their initial guidance. Cheers, Ralph. [1] https://github.com/jukka/pcfi/blob/master/src/main/resources/META-INF/LICENSE.txt [2] https://bugs.gentoo.org/show_bug.cgi?id=448532 A in-lined copy of the license follows: -- = PDF Core Font Information = This package contains PDF font information files downloaded from http://www.adobe.com/devnet/font/#pcfi and elsewhere. See the individual files and the summary below for related copyright and licensing information. Any Adobe patents covering information in these files should be included in the patent pledge they have made to ISO for the PDF 1.7 standard. Here's what Adobe legal wrote when asked about this: Adobe has provided a patent pledge to ISO which states that Adobe will grant a fee and royalty free license to an unrestricted number of applicants on a worldwide, non-discriminatory basis and under other reasonable terms and conditions to make, use, and sell implementations of PDF 1.7 (ISO 32000-1). (private communication to Jukka Zitting, 2008-12-03) See also the following page for more information about patents related to PDF: http://partners.adobe.com/public/developer/support/topic_legal_notices.html Font Metrics for PDF Core 14 Fonts -- The files in com/adobe/pdf/pcfi/afm were downloaded from http://www.adobe.com/devnet/font/pdfs/Core14_AFMs.zip on 2009-06-14. The MustRead.html file contains the following license: This file and the 14 PostScript(R) AFM files it accompanies may be used, copied, and distributed for any purpose and without charge, with or without modification, provided that all copyright notices are retained; that the AFM files are not distributed without this file; that all modifications to this file or any of the AFM files are prominently noted in the modified file(s); and that this paragraph is not modified. Adobe Systems has no responsibility or obligation to support the use of the AFM files. The individual AFM files contain further copyright notices. The aggregate of these notices is: Copyright (c) 1985, 1987, 1988, 1989, 1990, 1991, 1992, 1993, 1997 Adobe Systems Incorporated. All Rights Reserved. Helvetica and Times are trademarks of Linotype-Hell AG and/or its subsidiaries. ITC Zapf Dingbats is a registered trademark of International Typeface Corporation. CMaps for PDF CJK Fonts --- The CMap files in com/adobe/pdf/pcfi/*/ were downloaded from http://www.adobe.com/devnet/font/pdfs/ and elsewhere. All the individual CMap files in these directories contain copyright sections with a license for redistribution. The aggregate of this information is: Copyright 1990-2007 Adobe Systems Incorporated. All Rights Reserved. Patents Pending NOTICE: All information contained herein is the property of Adobe Systems Incorporated. Permission is granted for redistribution of this file provided this copyright notice is maintained intact and that the contents of this file are not altered in any way from its original form. PostScript and Display PostScript are trademarks of Adobe Systems Incorporated which may be registered in certain jurisdictions. Adobe Glyph List The glyph list in com/adobe/pdf/pcfi/glyphlist.txt was downloaded from http://www.adobe.com/devnet/opentype/archives/glyphlist.txt on 2010-08-06. Copyright (c) 1997,1998,2002,2007 Adobe Systems Incorporated Permission is hereby granted, free of charge, to any person obtaining a copy of this documentation file to use, copy, publish, distribute, sublicense, and/or sell copies of the documentation, and to permit others to do the same, provided that: - No modification, editing or other alteration of this document is allowed; and - The above copyright notice and this permission notice shall be included in all copies of the documentation. Permission is hereby granted, free of charge, to any person obtaining a copy of this documentation file, to create their own derivative works from the content of this document to use, copy, publish, distribute, sublicense, and/or sell the derivative works, and to permit others to do the same, provided that the derived work is not represented as being a copy or version of this document. Adobe shall not be liable to any party for any loss of revenue or profit or for indirect,
Re: [gentoo-dev] New license - adobe-pcfi
On Sun, 10 Mar 2013, Ralph Sennhauser wrote: I'm querying this list out of the need of adding a new license[1] for adobe-pcfi[2]. Suggested name for the license is adobe-pcfi. An other possibility could be Adobe-PCFI to better match other Adobe* licenses. If there are other Adobe* already, I'd use capital letters for this one too. The license would be added to the MISC-FREE license group. I believe that it's non-free, because the license notice for the CMaps for PDF CJK Fonts (which is also found in individual files in pcfi/tree/master/src/main/resources/com/adobe/pdf/pcfi/chinese_t) doesn't allow modification: CMaps for PDF CJK Fonts --- [...] Permission is granted for redistribution of this file provided this copyright notice is maintained intact and that the contents of this file are not altered in any way from its original form. This would imply that the license cannot be added to the MISC-FREE group. Ulrich [1] https://github.com/jukka/pcfi/blob/master/src/main/resources/META-INF/LICENSE.txt [2] https://bugs.gentoo.org/show_bug.cgi?id=448532 pgpFVeowdtpcy.pgp Description: PGP signature
[gentoo-dev] [PATCHES] multibuild.eclass: custom phase function helpers
Hello,
distutils-r1 (and previously python-distutils-ng) was using custom
phase functions for a while. Recently, hasufell added multilib-minimal
which does the same. Since in both cases the custom functions are
closely related to building multiple variants of the package, I'm
thinking of adding a few helper functions to the multibuild.eclass.
The framework I'm suggesting will make the custom phase functions
behave similarly to regular ones. Most importantly, eclasses will be
provided with a function to 'export' them.
I'm sending the following patches in reply to this thread:
1) introduces two functions to handle phases:
- multibuild_export_phases -- which exports the listed phases for
current eclass,
- multibuild_get_phase_function -- which finds and prints the best
handler for named phase.
The export/find logic follows one used for regular phases. If function
named ${phase} is declared, it is used. Otherwise, the function
exported by most recent eclass is used.
2) uses the new functions in distutils-r1,
3-4) general cleanup of multilib-minimal to make it suitable
for conversion,
5) uses the new functions in multilib-minimal,
6) runs multilib_src_configure() in parallel to save time,
7) makes autotools-multilib reuse multilib-minimal through exporting
sub-phase functions.
Comments? Questions?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH 1/7] multibuild: introduce a generic framework for custom phase functions.
The framework provides functions to declare, export and obtain custom
phase functions.
Each of the custom phases can be defined by eclasses and ebuilds
in a manner similar to regular phases. The eclasses define
${ECLASS}_${phase} function and run 'multibuild_export_phases' to
register them. The ebuilds define ${phase} function and it automatically
takes precedence over eclass-defined ones.
---
gx86/eclass/multibuild.eclass | 61 +++
1 file changed, 61 insertions(+)
diff --git a/gx86/eclass/multibuild.eclass b/gx86/eclass/multibuild.eclass
index bc510e9..ea0500c 100644
--- a/gx86/eclass/multibuild.eclass
+++ b/gx86/eclass/multibuild.eclass
@@ -28,6 +28,8 @@ if [[ ! ${_MULTIBUILD} ]]; then
inherit multiprocessing
+DEPEND==app-shells/bash-4.2
+
# @ECLASS-VARIABLE: MULTIBUILD_VARIANTS
# @DESCRIPTION:
# An array specifying all enabled variants which multibuild_foreach*
@@ -245,5 +247,64 @@ run_in_build_dir() {
return ${ret}
}
+# @FUNCTION: multibuild_export_phases
+# @USAGE: phase-name...
+# @DESCRIPTION:
+# Export the eclass phase functions for named phases. The functions need
+# be named ${ECLASS}_phase-name. The exported functions will override
+# any previously exported phases.
+multibuild_export_phases() {
+ debug-print-function ${FUNCNAME} ${@}
+
+ [[ ${#} -eq 0 ]] die Usage: multibuild_export_phases
phase-name...
+
+ # This is necessary to allow sourcing of the ebuild with old bash
+ # versions, e.g. for cachegen.
+ if [[ $(( (BASH_VERSINFO[0] 8) + BASH_VERSINFO[1] )) \
+ -lt $(( (4 8) + 2 )) ]] ; then
+ _MULTIBUILD_ANCIENT_BASH=1
+ return 0
+ fi
+
+ declare -g -A _MULTIBUILD_EXPORTED_PHASES || die
+ local p
+ for p; do
+ _MULTIBUILD_EXPORTED_PHASES[${p}]=${ECLASS}_${p}
+ done
+}
+
+# @FUNCTION: multibuild_get_phase_function
+# @USAGE: phase-name
+# @DESCRIPTION:
+# Find the topmost handler for the named phase. It can be either
+# user-defined phase handler (with the same name as the phase)
+# or a handler exported most recently by an eclass.
+#
+# Prints the function name to stdout or null string if there is
+# no handler for the phase.
+multibuild_get_phase_function() {
+ debug-print-function ${FUNCNAME} ${@}
+
+ [[ ${#} -ne 1 ]] die Usage: multibuild_get_phase_function
phase-name
+ if [[ ${_MULTIBUILD_ANCIENT_BASH} ]]; then
+ die Old bash (4.2) used to start the build, please restart
emerge.
+ fi
+
+ local phase=${1}
+
+ # user-defined phase
+ if ! declare -f ${phase} /dev/null; then
+ phase=${_MULTIBUILD_EXPORTED_PHASES[${phase}]}
+
+ if [[ ! ${phase} ]]; then
+ return
+ elif ! declare -f ${phase} /dev/null; then
+ die Phase function ${phase} exported but never
defined!
+ fi
+ fi
+
+ echo ${phase}
+}
+
_MULTIBUILD=1
fi
--
1.8.1.5
[gentoo-dev] [PATCH 3/7] multilib-minimal: split out mkdir to unify sub-functions.
---
gx86/eclass/multilib-minimal.eclass | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/gx86/eclass/multilib-minimal.eclass
b/gx86/eclass/multilib-minimal.eclass
index 070425f..a77368e 100644
--- a/gx86/eclass/multilib-minimal.eclass
+++ b/gx86/eclass/multilib-minimal.eclass
@@ -30,14 +30,18 @@ case ${EAPI:-0} in
esac
-inherit multilib-build
+inherit multibuild multilib-build
EXPORT_FUNCTIONS src_configure src_compile src_test src_install
multilib-minimal_src_configure() {
- multilib-minimal_abi_src_configure() {
+ _multilib-minimal_mkdir() {
mkdir -p ${BUILD_DIR} || die
+ }
+ multilib_foreach_abi _multilib-minimal_mkdir
+
+ multilib-minimal_abi_src_configure() {
pushd ${BUILD_DIR} /dev/null || die
if declare -f multilib_src_configure /dev/null ; then
multilib_src_configure
--
1.8.1.5
[gentoo-dev] [PATCH 4/7] multilib-minimal: reuse run_in_build_dir.
---
gx86/eclass/multilib-minimal.eclass | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/gx86/eclass/multilib-minimal.eclass
b/gx86/eclass/multilib-minimal.eclass
index a77368e..2510578 100644
--- a/gx86/eclass/multilib-minimal.eclass
+++ b/gx86/eclass/multilib-minimal.eclass
@@ -35,6 +35,10 @@ inherit multibuild multilib-build
EXPORT_FUNCTIONS src_configure src_compile src_test src_install
+_multilib-minimal_wrap_phase() {
+ run_in_build_dir ${@}
+}
+
multilib-minimal_src_configure() {
_multilib-minimal_mkdir() {
mkdir -p ${BUILD_DIR} || die
@@ -42,58 +46,50 @@ multilib-minimal_src_configure() {
multilib_foreach_abi _multilib-minimal_mkdir
multilib-minimal_abi_src_configure() {
- pushd ${BUILD_DIR} /dev/null || die
if declare -f multilib_src_configure /dev/null ; then
multilib_src_configure
else
default_src_configure
fi
- popd /dev/null || die
}
- multilib_foreach_abi multilib-minimal_abi_src_configure
+ multilib_foreach_abi _multilib-minimal_wrap_phase
multilib-minimal_abi_src_configure
}
multilib-minimal_src_compile() {
multilib-minimal_abi_src_compile() {
- pushd ${BUILD_DIR} /dev/null || die
if declare -f multilib_src_compile /dev/null ; then
multilib_src_compile
else
default_src_compile
fi
- popd /dev/null || die
}
- multilib_foreach_abi multilib-minimal_abi_src_compile
+ multilib_foreach_abi _multilib-minimal_wrap_phase
multilib-minimal_abi_src_compile
}
multilib-minimal_src_test() {
multilib-minimal_abi_src_test() {
- pushd ${BUILD_DIR} /dev/null || die
if declare -f multilib_src_test /dev/null ; then
multilib_src_test
else
default_src_test
fi
- popd /dev/null || die
}
- multilib_foreach_abi multilib-minimal_abi_src_test
+ multilib_foreach_abi _multilib-minimal_wrap_phase
multilib-minimal_abi_src_test
}
multilib-minimal_src_install() {
multilib-minimal_abi_src_install() {
- pushd ${BUILD_DIR} /dev/null || die
if declare -f multilib_src_install /dev/null ; then
multilib_src_install
else
default_src_install
fi
multilib_check_headers
- popd /dev/null || die
}
- multilib_foreach_abi multilib-minimal_abi_src_install
+ multilib_foreach_abi _multilib-minimal_wrap_phase
multilib-minimal_abi_src_install
if declare -f multilib_src_install_all /dev/null ; then
multilib_src_install_all
--
1.8.1.5
[gentoo-dev] [PATCH 2/7] distutils-r1: use multibuild phase helpers.
---
gx86/eclass/distutils-r1.eclass | 71 -
1 file changed, 27 insertions(+), 44 deletions(-)
diff --git a/gx86/eclass/distutils-r1.eclass b/gx86/eclass/distutils-r1.eclass
index 264ce9c..ce518a7 100644
--- a/gx86/eclass/distutils-r1.eclass
+++ b/gx86/eclass/distutils-r1.eclass
@@ -92,6 +92,8 @@ fi
if [[ ! ${DISTUTILS_OPTIONAL} ]]; then
EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test
src_install
fi
+multibuild_export_phases \
+ python_prepare_all python_compile python_install python_install_all
if [[ ! ${_DISTUTILS_R1} ]]; then
@@ -559,6 +561,9 @@ distutils-r1_run_phase() {
# If in-source build is used, the command will be run in the copy
# of sources made for the best Python interpreter.
_distutils-r1_run_common_phase() {
+ # not all phases need be set
+ [[ ${1} ]] || return
+
local DISTUTILS_ORIG_BUILD_DIR=${BUILD_DIR}
local MULTIBUILD_VARIANTS
@@ -576,6 +581,9 @@ _distutils-r1_run_common_phase() {
_distutils-r1_run_foreach_impl() {
debug-print-function ${FUNCNAME} ${@}
+ # not all phases need be set
+ [[ ${1} ]] || return
+
set -- distutils-r1_run_phase ${@}
if [[ ! ${DISTUTILS_SINGLE_IMPL} ]]; then
@@ -599,68 +607,43 @@ _distutils-r1_run_foreach_impl() {
distutils-r1_src_prepare() {
debug-print-function ${FUNCNAME} ${@}
- # common preparations
- if declare -f python_prepare_all /dev/null; then
- python_prepare_all
- else
- distutils-r1_python_prepare_all
- fi
-
- if declare -f python_prepare /dev/null; then
- _distutils-r1_run_foreach_impl python_prepare
- fi
+ $(multibuild_get_phase_function python_prepare_all)
+ _distutils-r1_run_foreach_impl \
+ $(multibuild_get_phase_function python_prepare)
}
distutils-r1_src_configure() {
- if declare -f python_configure /dev/null; then
- _distutils-r1_run_foreach_impl python_configure
- fi
-
- if declare -f python_configure_all /dev/null; then
- _distutils-r1_run_common_phase python_configure_all
- fi
+ _distutils-r1_run_foreach_impl \
+ $(multibuild_get_phase_function python_configure)
+ _distutils-r1_run_common_phase \
+ $(multibuild_get_phase_function python_configure_all)
}
distutils-r1_src_compile() {
debug-print-function ${FUNCNAME} ${@}
- if declare -f python_compile /dev/null; then
- _distutils-r1_run_foreach_impl python_compile
- else
- _distutils-r1_run_foreach_impl distutils-r1_python_compile
- fi
-
- if declare -f python_compile_all /dev/null; then
- _distutils-r1_run_common_phase python_compile_all
- fi
+ _distutils-r1_run_foreach_impl \
+ $(multibuild_get_phase_function python_compile)
+ _distutils-r1_run_common_phase \
+ $(multibuild_get_phase_function python_compile_all)
}
distutils-r1_src_test() {
debug-print-function ${FUNCNAME} ${@}
- if declare -f python_test /dev/null; then
- _distutils-r1_run_foreach_impl python_test
- fi
-
- if declare -f python_test_all /dev/null; then
- _distutils-r1_run_common_phase python_test_all
- fi
+ _distutils-r1_run_foreach_impl \
+ $(multibuild_get_phase_function python_test)
+ _distutils-r1_run_common_phase \
+ $(multibuild_get_phase_function python_test_all)
}
distutils-r1_src_install() {
debug-print-function ${FUNCNAME} ${@}
- if declare -f python_install /dev/null; then
- _distutils-r1_run_foreach_impl python_install
- else
- _distutils-r1_run_foreach_impl distutils-r1_python_install
- fi
-
- if declare -f python_install_all /dev/null; then
- _distutils-r1_run_common_phase python_install_all
- else
- _distutils-r1_run_common_phase distutils-r1_python_install_all
- fi
+ _distutils-r1_run_foreach_impl \
+ $(multibuild_get_phase_function python_install)
+ _distutils-r1_run_common_phase \
+ $(multibuild_get_phase_function python_install_all)
}
_DISTUTILS_R1=1
--
1.8.1.5
[gentoo-dev] [PATCH 6/7] multilib-minimal: run multilib_src_configure in parallel.
---
gx86/eclass/multilib-minimal.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gx86/eclass/multilib-minimal.eclass
b/gx86/eclass/multilib-minimal.eclass
index 2a707b1..cfe4eef 100644
--- a/gx86/eclass/multilib-minimal.eclass
+++ b/gx86/eclass/multilib-minimal.eclass
@@ -46,7 +46,7 @@ multilib-minimal_src_configure() {
multilib_foreach_abi _multilib-minimal_mkdir
local phase=$(multibuild_get_phase_function multilib_src_configure)
- multilib_foreach_abi \
+ multilib_parallel_foreach_abi \
_multilib-minimal_wrap_phase ${phase:-default_src_configure}
}
--
1.8.1.5
[gentoo-dev] [PATCH 7/7] autotools-multilib: reuse phase functions from multilib-minimal.
This makes replacing sub-phase functions much easier.
---
gx86/eclass/autotools-multilib.eclass | 34 --
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/gx86/eclass/autotools-multilib.eclass
b/gx86/eclass/autotools-multilib.eclass
index d7372b0..d04fd1f 100644
--- a/gx86/eclass/autotools-multilib.eclass
+++ b/gx86/eclass/autotools-multilib.eclass
@@ -29,33 +29,47 @@ if [[ ${AUTOTOOLS_IN_SOURCE_BUILD} ]]; then
die ${ECLASS}: multilib support requires out-of-source builds.
fi
-inherit autotools-utils multilib-build
+inherit autotools-utils multibuild multilib-minimal
EXPORT_FUNCTIONS src_prepare src_configure src_compile src_test src_install
+multibuild_export_phases \
+ multilib_src_configure multilib_src_compile multilib_src_test \
+ multilib_src_install
autotools-multilib_src_prepare() {
autotools-utils_src_prepare ${@}
}
autotools-multilib_src_configure() {
- multilib_parallel_foreach_abi autotools-utils_src_configure ${@}
+ multilib-minimal_src_configure ${@}
}
autotools-multilib_src_compile() {
- multilib_foreach_abi autotools-utils_src_compile ${@}
+ multilib-minimal_src_compile ${@}
}
autotools-multilib_src_test() {
- multilib_foreach_abi autotools-utils_src_test ${@}
+ multilib-minimal_src_test ${@}
}
autotools-multilib_src_install() {
- autotools-multilib_secure_install() {
- autotools-utils_src_install ${@}
+ multilib-minimal_src_install ${@}
+}
+
+# multilib-minimal phases
+
+autotools-multilib_multilib_src_configure() {
+ autotools-utils_src_configure ${@}
+}
- # Make sure all headers are the same for each ABI.
- multilib_check_headers
- }
+autotools-multilib_multilib_src_compile() {
+ autotools-utils_src_compile ${@}
+}
+
+autotools-multilib_multilib_src_test() {
+ autotools-utils_src_test ${@}
+}
- multilib_foreach_abi autotools-multilib_secure_install ${@}
+autotools-multilib_multilib_src_install() {
+ autotools-utils_src_install ${@}
}
--
1.8.1.5
[gentoo-dev] [PATCH 5/7] multilib-minimal: reuse multibuild phase function handlers.
---
gx86/eclass/multilib-minimal.eclass | 54 -
1 file changed, 17 insertions(+), 37 deletions(-)
diff --git a/gx86/eclass/multilib-minimal.eclass
b/gx86/eclass/multilib-minimal.eclass
index 2510578..2a707b1 100644
--- a/gx86/eclass/multilib-minimal.eclass
+++ b/gx86/eclass/multilib-minimal.eclass
@@ -45,53 +45,33 @@ multilib-minimal_src_configure() {
}
multilib_foreach_abi _multilib-minimal_mkdir
- multilib-minimal_abi_src_configure() {
- if declare -f multilib_src_configure /dev/null ; then
- multilib_src_configure
- else
- default_src_configure
- fi
- }
-
- multilib_foreach_abi _multilib-minimal_wrap_phase
multilib-minimal_abi_src_configure
+ local phase=$(multibuild_get_phase_function multilib_src_configure)
+ multilib_foreach_abi \
+ _multilib-minimal_wrap_phase ${phase:-default_src_configure}
}
multilib-minimal_src_compile() {
- multilib-minimal_abi_src_compile() {
- if declare -f multilib_src_compile /dev/null ; then
- multilib_src_compile
- else
- default_src_compile
- fi
- }
-
- multilib_foreach_abi _multilib-minimal_wrap_phase
multilib-minimal_abi_src_compile
+ local phase=$(multibuild_get_phase_function multilib_src_compile)
+ multilib_foreach_abi \
+ _multilib-minimal_wrap_phase ${phase:-default_src_compile}
}
multilib-minimal_src_test() {
- multilib-minimal_abi_src_test() {
- if declare -f multilib_src_test /dev/null ; then
- multilib_src_test
- else
- default_src_test
- fi
- }
-
- multilib_foreach_abi _multilib-minimal_wrap_phase
multilib-minimal_abi_src_test
+ local phase=$(multibuild_get_phase_function multilib_src_test)
+ multilib_foreach_abi \
+ _multilib-minimal_wrap_phase ${phase:-default_src_test}
}
multilib-minimal_src_install() {
- multilib-minimal_abi_src_install() {
- if declare -f multilib_src_install /dev/null ; then
- multilib_src_install
- else
- default_src_install
- fi
+ _multilib-minimal_wrap_install_phase() {
+ _multilib-minimal_wrap_phase ${@}
multilib_check_headers
}
- multilib_foreach_abi _multilib-minimal_wrap_phase
multilib-minimal_abi_src_install
- if declare -f multilib_src_install_all /dev/null ; then
- multilib_src_install_all
- fi
+ local phase=$(multibuild_get_phase_function multilib_src_install)
+ multilib_foreach_abi \
+ _multilib-minimal_wrap_install_phase
${phase:-default_src_install}
+
+ phase=$(multibuild_get_phase_function multilib_src_install_all)
+ [[ ${phase} ]] ${phase}
}
--
1.8.1.5
Re: [gentoo-dev] New license - adobe-pcfi
On Sun, Mar 10, 2013 at 11:01:55AM +0100, Ulrich Mueller wrote: CMaps for PDF CJK Fonts --- [...] Permission is granted for redistribution of this file provided this copyright notice is maintained intact and that the contents of this file are not altered in any way from its original form. This would imply that the license cannot be added to the MISC-FREE group. Ok, I think @BINARY-REDISTRIBUTABLE may be workable instead for this license. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] [PATCH 1/7] multibuild: introduce a generic framework for custom phase functions.
On Sun, 10 Mar 2013, Michał Górny wrote: +DEPEND==app-shells/bash-4.2 + Why is this needed? Ulrich
Re: [gentoo-dev] [PATCH 1/7] multibuild: introduce a generic framework for custom phase functions.
On Sun, 10 Mar 2013, Ulrich Mueller wrote:
On Sun, 10 Mar 2013, Michał Górny wrote:
+DEPEND==app-shells/bash-4.2
+
Why is this needed?
Seems it's because of this:
+declare -g -A _MULTIBUILD_EXPORTED_PHASES || die
+local p
+for p; do
+_MULTIBUILD_EXPORTED_PHASES[${p}]=${ECLASS}_${p}
+done
Associative arrays are not supported in bash 3.2, so they must not be
used in EAPIs 0 to 5.
Ulrich
Re: [gentoo-dev] [PATCH 1/7] multibuild: introduce a generic framework for custom phase functions.
On Sun, 10 Mar 2013 13:16:46 +0100
Ulrich Mueller u...@gentoo.org wrote:
On Sun, 10 Mar 2013, Ulrich Mueller wrote:
On Sun, 10 Mar 2013, Michał Górny wrote:
+DEPEND==app-shells/bash-4.2
+
Why is this needed?
Seems it's because of this:
+ declare -g -A _MULTIBUILD_EXPORTED_PHASES || die
+ local p
+ for p; do
+ _MULTIBUILD_EXPORTED_PHASES[${p}]=${ECLASS}_${p}
+ done
Associative arrays are not supported in bash 3.2, so they must not be
used in EAPIs 0 to 5.
A dependency upon a newer bash doesn't guarantee that the package
mangler will use that bash.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH 1/7] multibuild: introduce a generic framework for custom phase functions.
On Sun, 10 Mar 2013 12:18:25 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Sun, 10 Mar 2013 13:16:46 +0100
Ulrich Mueller u...@gentoo.org wrote:
On Sun, 10 Mar 2013, Ulrich Mueller wrote:
On Sun, 10 Mar 2013, Michał Górny wrote:
+DEPEND==app-shells/bash-4.2
+
Why is this needed?
Seems it's because of this:
+declare -g -A _MULTIBUILD_EXPORTED_PHASES || die
+local p
+for p; do
+_MULTIBUILD_EXPORTED_PHASES[${p}]=${ECLASS}_${p}
+done
Associative arrays are not supported in bash 3.2, so they must not be
used in EAPIs 0 to 5.
A dependency upon a newer bash doesn't guarantee that the package
mangler will use that bash.
Yep. That's why the non-quoted fragment has a safety check and dies if
it doesn't.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs
On Sat, 9 Mar 2013 11:10:11 +0100
Alexis Ballier aball...@gentoo.org wrote:
On Fri, 8 Mar 2013 17:30:10 +0100
Michał Górny mgo...@gentoo.org wrote:
We're talking about two different tricks.
Busybox checks argv to support symlinking for a standard tool. With
invalid argv[0], it still runs as the standard busybox binary. You can
use it that way, the 'safe way'.
Unless I'm missing something, git checks argv to support symlinking
into a few dozen tools which is optional. I doubt most of our users
rely on that rather than using the 'git foo' syntax.
A wrapper needs valid argv[0] to find the actual executable. Since
argv[0] is unlikely to contain a path, that's either reinventing some
logic or execvp() which is a bit fragile. Plus symlink resolution
loop. Hard links do not work at all.
And that's just theory. I may be missing some of the dangers.
abiwrapper with invalid argv will print a standard help message too :)
Help message won't help users.
We're very sorry, that won't work. Don't bother reporting it to
upstream, it's Gentoo-specific hack, they'll just WONTFIX them. Feel
free to report it here, we may be able to clean the mess up someday.
We're basically talking about opt-out. We introduce a trick which fails
in corner cases by default, hoping those cases won't happen. People
start to rely on it. Then the corner case happens and we need to
opt-out, and we need to fix everything that started to rely
on the common case working.
I don't see why you consider execvp fragile: Don't tell me you run all
your binaries with full path.
Of course you can break it, but the question is more: Is it likely to
break in a real life situation?
I think that was one of the things that were pointed out in the initial
python-exec implementation. It's not broken that much as a bit
inconsistent by design. As in, wrapper /usr/bin/foo-config doesn't
guarantee that /usr/bin/foo-config-${ARCH} will be called (maybe
something in /usr/local/bin or somewhere completely different?).
If you consider the argv trick fragile, which is understandable, the
same wrapper idea can be used differently: If you want to wrap a
binary foo, move it to foo_${abi} and build a wrapper with hardcoded
'foo' instead of argv[0] that you install as foo. You can even hardcode
its path and use execv instead of execvp. That would invalidate all
your above objections I think :)
Well, yes. In the worst case we could go that way, although it's a bit
of overkill, don't you think? While we're talking about a few programs
which will actually need it, and even less which will require
modification in more than one place.
Let alone qmake, how do you suggest dealing with *-config scripts?
Some packages are just not written with multilib in mind, or have
to maintain historical compatibility which was not, wrapping the
problematic binaries is one solution to this. I've not seen any other
solution.
Choose optimal solution per-package. In case of freetype, the solution
is simple enough: make multilib-aware packages use pkg-config.
fontconfig does exactly that, and in the earlier version it was enough
to export something like FREETYPE_CONFIG='pkg-config freetype2'
(or ac_cv...).
In LLVM, for example, we were considering just calling the proper
config by hand. It's a single multilib package which will need it now,
so it's not that problematic.
If you have any specific -config scripts in mind, please point me
to them. By the way, from what I recall Tommy said that llvm is
basically the only -config script being actually compiled executable.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH 1/7] multibuild: introduce a generic framework for custom phase functions.
On Sun, 10 Mar 2013, Michał Górny wrote: Yep. That's why the non-quoted fragment has a safety check and dies if it doesn't. It doesn't matter if there's a safety check. Bash 4 features are simply not allowed in the tree. Ulrich
Re: [gentoo-dev] [PATCH 1/7] multibuild: introduce a generic framework for custom phase functions.
On Sun, 10 Mar 2013 14:44:42 +0100 Ulrich Mueller u...@gentoo.org wrote: On Sun, 10 Mar 2013, Michał Górny wrote: Yep. That's why the non-quoted fragment has a safety check and dies if it doesn't. It doesn't matter if there's a safety check. Bash 4 features are simply not allowed in the tree. Is there a technical reason for that? As far as I understand it, the method used in the ebuild should guarantee that in the worst case user would have to restart emerge once. Well, unless we're talking about a theoretical package mangler which intentionally uses internal, old version of bash to prove the point. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 1/7] multibuild: introduce a generic framework for custom phase functions.
On Sun, 10 Mar 2013 14:48:06 +0100 Michał Górny mgo...@gentoo.org wrote: Well, unless we're talking about a theoretical package mangler which intentionally uses internal, old version of bash to prove the point. That's a good idea, maybe we'll do that. Sounds like a good way of doing better input validation. Perhaps we could patch our internal bash to make it easier to catch certain other errors too. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 1/7] multibuild: introduce a generic framework for custom phase functions.
On Sun, 10 Mar 2013 15:26:29 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sun, 10 Mar 2013 14:48:06 +0100 Michał Górny mgo...@gentoo.org wrote: Well, unless we're talking about a theoretical package mangler which intentionally uses internal, old version of bash to prove the point. That's a good idea, maybe we'll do that. Sounds like a good way of doing better input validation. Perhaps we could patch our internal bash to make it easier to catch certain other errors too. Please don't forget to bundle a few rootkits inside, so your users won't have to wait for security issues to be found in the ye ol' bash version you'll use. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 1/7] multibuild: introduce a generic framework for custom phase functions.
On Sun, 10 Mar 2013 16:46:41 +0100 Michał Górny mgo...@gentoo.org wrote: On Sun, 10 Mar 2013 15:26:29 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sun, 10 Mar 2013 14:48:06 +0100 Michał Górny mgo...@gentoo.org wrote: Well, unless we're talking about a theoretical package mangler which intentionally uses internal, old version of bash to prove the point. That's a good idea, maybe we'll do that. Sounds like a good way of doing better input validation. Perhaps we could patch our internal bash to make it easier to catch certain other errors too. Please don't forget to bundle a few rootkits inside, so your users won't have to wait for security issues to be found in the ye ol' bash version you'll use. You mean, in the bash that will be being run as root, that is accessible exclusively to packages, all of which are allowed to run things as root, install set*id binaries, etc? -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] [PATCH] multibuild: introduce a generic framework for custom phase functions.
The framework provides functions to declare, export and obtain custom
phase functions.
Each of the custom phases can be defined by eclasses and ebuilds
in a manner similar to regular phases. The eclasses define
${ECLASS}_${phase} function and run 'multibuild_export_phases' to
register them. The ebuilds define ${phase} function and it automatically
takes precedence over eclass-defined ones.
---
gx86/eclass/multibuild.eclass | 66 +++
1 file changed, 66 insertions(+)
diff --git a/gx86/eclass/multibuild.eclass b/gx86/eclass/multibuild.eclass
index bc510e9..3187c9e 100644
--- a/gx86/eclass/multibuild.eclass
+++ b/gx86/eclass/multibuild.eclass
@@ -245,5 +245,71 @@ run_in_build_dir() {
return ${ret}
}
+# @ECLASS-VARIABLE: _MULTIBUILD_EXPORTED_PHASES
+# @INTERNAL
+# @DESCRIPTION:
+# The list of currently exported phase functions.
+#
+# Each function is stored in the form of 'eclass:phase-name'.
+# New exports are prepended to the list, so the first matching value
+# is the most recent one.
+_MULTIBUILD_EXPORTED_PHASES=()
+
+# @FUNCTION: multibuild_export_phases
+# @USAGE: phase-name...
+# @DESCRIPTION:
+# Export the eclass phase functions for named phases. The functions need
+# be named ${ECLASS}_phase-name. The exported functions will override
+# any previously exported phases.
+multibuild_export_phases() {
+ debug-print-function ${FUNCNAME} ${@}
+
+ [[ ${#} -eq 0 ]] die Usage: multibuild_export_phases
phase-name...
+
+ # just prepend to the list
+ _MULTIBUILD_EXPORTED_PHASES=(
+ ${@/#/${ECLASS}:}
+ ${_MULTIBUILD_EXPORTED_PHASES[@]}
+ )
+}
+
+# @FUNCTION: multibuild_get_phase_function
+# @USAGE: phase-name
+# @DESCRIPTION:
+# Find the topmost handler for the named phase. It can be either
+# user-defined phase handler (with the same name as the phase)
+# or a handler exported most recently by an eclass.
+#
+# Prints the function name to stdout or null string if there is
+# no handler for the phase.
+multibuild_get_phase_function() {
+ debug-print-function ${FUNCNAME} ${@}
+
+ [[ ${#} -ne 1 ]] die Usage: multibuild_get_phase_function
phase-name
+
+ local phase=${1}
+
+ # user-defined phase
+ if ! declare -f ${phase} /dev/null; then
+ local found p
+ for p in ${_MULTIBUILD_EXPORTED_PHASES[@]}; do
+ if [[ ${p} == *:${phase} ]]; then
+ # we're breaking out, so we can overwrite it.
+ phase=${p/:/_}
+ found=1
+ break
+ fi
+ done
+
+ if [[ ! ${found} ]]; then
+ return
+ elif ! declare -f ${phase} /dev/null; then
+ die Phase function ${phase} exported but never
defined!
+ fi
+ fi
+
+ echo ${phase}
+}
+
_MULTIBUILD=1
fi
--
1.8.1.5
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
On Sun, 3 Mar 2013 12:44:18 +0100 Tomáš Chvátal tomas.chva...@gmail.com wrote: If I remember correctly the damn rule is to put it for 30 days into testing, and as you said there was no previous version on arm so users could've reported some issues, i agree that sometimes you have to ignore the rules to really fix stable, but was this such case for sure? I've done straight to stable keywording _many_ times. The rationale is that with no previous version stable for a particular architecture, there really are no users who could see _regressions_, hence waiting the nominal thirty days is meaningless in this case. jer
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
On 03/10/2013 07:04 PM, Jeroen Roovers wrote: On Sun, 3 Mar 2013 12:44:18 +0100 Tomáš Chvátal tomas.chva...@gmail.com wrote: If I remember correctly the damn rule is to put it for 30 days into testing, and as you said there was no previous version on arm so users could've reported some issues, i agree that sometimes you have to ignore the rules to really fix stable, but was this such case for sure? I've done straight to stable keywording _many_ times. The rationale is that with no previous version stable for a particular architecture, there really are no users who could see _regressions_, hence waiting the nominal thirty days is meaningless in this case. jer another note: I was told a while back (I might still have it in irc logs), that 30 days is NOT a rule. It's common sense, but in the end the maintainer decides when to request stabilization, no one else. Blame people if they break something, not if they ignore soft policies.
Re: [gentoo-dev] [PATCH] multibuild: introduce a generic framework for custom phase functions.
On Sun, Mar 10, 2013 at 8:50 AM, Michał Górny mgo...@gentoo.org wrote:
The framework provides functions to declare, export and obtain custom
phase functions.
Thanks for fixing this up.
-A
Each of the custom phases can be defined by eclasses and ebuilds
in a manner similar to regular phases. The eclasses define
${ECLASS}_${phase} function and run 'multibuild_export_phases' to
register them. The ebuilds define ${phase} function and it automatically
takes precedence over eclass-defined ones.
---
gx86/eclass/multibuild.eclass | 66
+++
1 file changed, 66 insertions(+)
diff --git a/gx86/eclass/multibuild.eclass b/gx86/eclass/multibuild.eclass
index bc510e9..3187c9e 100644
--- a/gx86/eclass/multibuild.eclass
+++ b/gx86/eclass/multibuild.eclass
@@ -245,5 +245,71 @@ run_in_build_dir() {
return ${ret}
}
+# @ECLASS-VARIABLE: _MULTIBUILD_EXPORTED_PHASES
+# @INTERNAL
+# @DESCRIPTION:
+# The list of currently exported phase functions.
+#
+# Each function is stored in the form of 'eclass:phase-name'.
+# New exports are prepended to the list, so the first matching value
+# is the most recent one.
+_MULTIBUILD_EXPORTED_PHASES=()
+
+# @FUNCTION: multibuild_export_phases
+# @USAGE: phase-name...
+# @DESCRIPTION:
+# Export the eclass phase functions for named phases. The functions need
+# be named ${ECLASS}_phase-name. The exported functions will override
+# any previously exported phases.
+multibuild_export_phases() {
+ debug-print-function ${FUNCNAME} ${@}
+
+ [[ ${#} -eq 0 ]] die Usage: multibuild_export_phases
phase-name...
+
+ # just prepend to the list
+ _MULTIBUILD_EXPORTED_PHASES=(
+ ${@/#/${ECLASS}:}
+ ${_MULTIBUILD_EXPORTED_PHASES[@]}
+ )
+}
+
+# @FUNCTION: multibuild_get_phase_function
+# @USAGE: phase-name
+# @DESCRIPTION:
+# Find the topmost handler for the named phase. It can be either
+# user-defined phase handler (with the same name as the phase)
+# or a handler exported most recently by an eclass.
+#
+# Prints the function name to stdout or null string if there is
+# no handler for the phase.
+multibuild_get_phase_function() {
+ debug-print-function ${FUNCNAME} ${@}
+
+ [[ ${#} -ne 1 ]] die Usage: multibuild_get_phase_function
phase-name
+
+ local phase=${1}
+
+ # user-defined phase
+ if ! declare -f ${phase} /dev/null; then
+ local found p
+ for p in ${_MULTIBUILD_EXPORTED_PHASES[@]}; do
+ if [[ ${p} == *:${phase} ]]; then
+ # we're breaking out, so we can overwrite it.
+ phase=${p/:/_}
+ found=1
+ break
+ fi
+ done
+
+ if [[ ! ${found} ]]; then
+ return
+ elif ! declare -f ${phase} /dev/null; then
+ die Phase function ${phase} exported but never
defined!
+ fi
+ fi
+
+ echo ${phase}
+}
+
_MULTIBUILD=1
fi
--
1.8.1.5
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
On 03/10/2013 02:11 PM, hasufell wrote: On 03/10/2013 07:04 PM, Jeroen Roovers wrote: On Sun, 3 Mar 2013 12:44:18 +0100 Tomáš Chvátal tomas.chva...@gmail.com wrote: If I remember correctly the damn rule is to put it for 30 days into testing, and as you said there was no previous version on arm so users could've reported some issues, i agree that sometimes you have to ignore the rules to really fix stable, but was this such case for sure? I've done straight to stable keywording _many_ times. The rationale is that with no previous version stable for a particular architecture, there really are no users who could see _regressions_, hence waiting the nominal thirty days is meaningless in this case. jer another note: I was told a while back (I might still have it in irc logs), that 30 days is NOT a rule. It's common sense, but in the end the maintainer decides when to request stabilization, no one else. Blame people if they break something, not if they ignore soft policies. What's broken is the expectation that the package was tested by more than one person. The soft policy is here: http://devmanual.gentoo.org/keywording/index.html#moving-from-~arch-to-arch And you're right, ~30 days is simply a suggestion. But the rule is The package has spent a reasonable amount of time in ~arch first. A further non-suggestion is The package must be widely tested. If a package is marked stable, I expect it to have seen some testing, and not just on the maintainers personal machine. I don't rely 100% on the stable designation, but it does affect the amount of testing that I personally will do. Please help me do my job by not perverting the meaning of stable.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
hasufell posted on Sun, 10 Mar 2013 19:11:52 +0100 as excerpted: I was told a while back (I might still have it in irc logs), that 30 days is NOT a rule. It's common sense, but in the end the maintainer decides when to request stabilization, no one else. I can confirm the 30-day-guideline policy was just that, a maintainer- discretion guideline, back in 2005/2006 or so when I first became aware of the concept via discussion. It was explained as maintainer knows their packages best, with the caveat that arch-teams also knew their archs best and could choose not to stabilize right away if they decided the request wasn't appropriate for their arch. I've seen no council, etc. decision changing that, over the years. Sometime a bit thereafter, various understaffed archs began to yield stabilizing authority to non-arch-team maintainers on a package-by- package basis, generally with at least the requirement that said maintainer actually had access to and had tested on that arch. AFAIK, before that maintainers weren't to stabilize at all on archs they weren't team members of, but they could still do so if they were a member of the arch-team, provided of course that they were following arch-team policy in the process. Meanwhile, jer's explanation, that on an arch where the package was not previously stable, there could be no stable users of the app to see regressions, so straight to stable makes a bit more sense, makes perfect sense to me. =:^) If I'm arguably too verbose, vapier's arguably not verbose enough. Had he just said something like either of these instead of simply punting with his replies... I guess it would have stopped there. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] [RFC] gentoo-openstack project
Starting up a new project (gentoo-openstack). It is currently a subproject of virtualization and our project page can be found here. http://www.gentoo.org/proj/en/virtualization/openstack/ The current goals are to flesh out the support for Openstack on Gentoo (we have the ebuilds in tree, but initscripts and the like need some work). We also want to maintain better security release upstream (as they do not make interim security releases during their release cycle. We have a bug alias as well as a list (openstack and gentoo-openstack respectively). Any advice is welcome :D -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-03-10 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2013-03-10 23h59 UTC. Removals: virtual/c++-tr1-functional 2013-03-05 13:35:56 flameeyes virtual/c++-tr1-memory 2013-03-05 13:35:56 flameeyes virtual/c++-tr1-type-traits 2013-03-05 13:35:57 flameeyes net-p2p/leechcraft-eiskaltdcpp 2013-03-08 21:47:03 maksbotan app-editors/leechcraft-popishu 2013-03-09 07:21:19 maksbotan media-sound/leechcraft-hotstreams 2013-03-09 07:23:15 maksbotan media-sound/leechcraft-lastfmscrobble 2013-03-09 07:23:32 maksbotan media-sound/leechcraft-lmp 2013-03-09 07:23:52 maksbotan media-sound/leechcraft-musiczombie 2013-03-09 07:24:11 maksbotan media-sound/leechcraft-touchstreams 2013-03-09 07:24:29 maksbotan media-video/leechcraft-laure2013-03-09 07:24:56 maksbotan net-analyzer/leechcraft-networkmonitor 2013-03-09 07:25:31 maksbotan net-ftp/leechcraft-lcftp2013-03-09 07:25:49 maksbotan net-im/leechcraft-azoth 2013-03-09 07:26:09 maksbotan net-misc/leechcraft-advancednotifications 2013-03-09 07:26:39 maksbotan net-misc/leechcraft-anhero 2013-03-09 07:26:59 maksbotan net-misc/leechcraft-auscrie 2013-03-09 07:27:18 maksbotan net-misc/leechcraft-blogique2013-03-09 07:27:39 maksbotan net-misc/leechcraft-core2013-03-09 07:28:00 maksbotan net-misc/leechcraft-cstp2013-03-09 07:28:24 maksbotan net-misc/leechcraft-dbusmanager 2013-03-09 07:28:45 maksbotan net-misc/leechcraft-full2013-03-09 07:29:08 maksbotan net-misc/leechcraft-gacts 2013-03-09 07:29:28 maksbotan net-misc/leechcraft-glance 2013-03-09 07:29:48 maksbotan net-misc/leechcraft-historyholder 2013-03-09 07:30:08 maksbotan net-misc/leechcraft-kinotify2013-03-09 07:30:29 maksbotan net-misc/leechcraft-knowhow 2013-03-09 07:30:48 maksbotan net-misc/leechcraft-lackman 2013-03-09 07:31:15 maksbotan net-misc/leechcraft-launchy 2013-03-09 07:31:39 maksbotan net-misc/leechcraft-lemon 2013-03-09 07:32:14 maksbotan net-misc/leechcraft-liznoo 2013-03-09 07:32:42 maksbotan net-misc/leechcraft-netstoremanager 2013-03-09 07:33:03 maksbotan net-misc/leechcraft-newlife 2013-03-09 07:33:26 maksbotan net-misc/leechcraft-otlozhu 2013-03-09 07:33:47 maksbotan net-misc/leechcraft-pintab 2013-03-09 07:34:07 maksbotan net-misc/leechcraft-qrosp 2013-03-09 07:34:28 maksbotan net-misc/leechcraft-sb2 2013-03-09 07:34:48 maksbotan net-misc/leechcraft-secman 2013-03-09 07:35:09 maksbotan net-misc/leechcraft-sidebar 2013-03-09 07:35:32 maksbotan net-misc/leechcraft-summary 2013-03-09 07:35:53 maksbotan net-misc/leechcraft-tabpp 2013-03-09 07:36:13 maksbotan net-misc/leechcraft-tabsessmanager 2013-03-09 07:36:34 maksbotan net-misc/leechcraft-tabslist2013-03-09 07:36:54 maksbotan net-news/leechcraft-aggregator 2013-03-09 07:37:12 maksbotan net-p2p/leechcraft-bittorrent 2013-03-09 07:37:29 maksbotan net-proxy/leechcraft-xproxy 2013-03-09 07:38:01 maksbotan sys-fs/leechcraft-vrooby2013-03-09 07:38:24 maksbotan www-client/leechcraft-deadlyrics2013-03-09 07:38:46 maksbotan www-client/leechcraft-dolozhee 2013-03-09 07:39:00 maksbotan
