Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El sáb, 12-01-2013 a las 04:49 -0800, Zac Medico escribió:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/12/2013 02:34 AM, Pacho Ramos wrote:
El sáb, 12-01-2013 a las 02:01 -0800, Zac Medico escribió:
On 01/12/2013 01:46 AM, Pacho Ramos wrote:
El mié, 09-01-2013 a las 12:04 -0800, Zac Medico escribió:
On 01/09/2013 11:53 AM, Pacho Ramos wrote:
This changes the name of eclass to readme.gentoo.eclass and
gets information from ${FILESDIR}/README.gentoo
What if there are multiple versions/slots that have
different README.gentoo content? Maybe the eclass should
accommodate that somehow?
This should work, it will read DOC_CONTENTS variable from
ebuild and, if not set, rely on common
${FILESDIR}/README.gentoo
You might add a loop to search for a version-specific
README.gentoo, like this:
file= for suffix in -${PV} -${PV}-${PR} ; do [[ -f
${FILESDIR}/README.gentoo${suffix} ]] \
file=${FILESDIR}/README.gentoo${suffix} break done if [[
${file} ]] ; then cp ${file} ${T}/README.gentoo dodoc
${T}/README.gentoo fi
Thank for explaining me how to do that. The problem is that I doubt
if it would really be useful as we usually won't need whan
README.gentoo per version, only to update if for some special cases
from time to time :/
For example: foo-1.0 relies on common README.gentoo file, foo-1.1
adds new feature and, then, would use README.gentoo-1.1 file... but
foo-1.2 will probably use the same README.gentoo-1.1 file :|
Still, it maybe it would be reasonable to use a different
README.gentoo for each SLOT, it there's more than one? Maybe it makes
more sense to have another variable like DOC_CONTENTS, but have it
refer to a filename? Then you should have multiple revisions of an
ebuild refer to the same file, without having to have duplicate
CONTENTS settings.
- --
Thanks,
Zac
What about this approach?
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: readme.gentoo
# @MAINTAINER:
# Pacho Ramos pa...@gentoo.org
# @AUTHOR:
# Author: Pacho Ramos pa...@gentoo.org
# @BLURB: An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
# @DESCRIPTION:
# An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
if [[ ${___ECLASS_ONCE_README_GENTOO} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_README_GENTOO=recur -_+^+_- spank
inherit eutils
case ${EAPI:-0} in
0|1|2|3)
die Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}
;;
4|5)
# EAPI=4 is required for REPLACING_VERSIONS preventing us
# from needing to export another pkg_preinst phase to save has_version
# result. Also relies on EAPI =4 default src_install phase.
;;
*)
die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
;;
esac
EXPORT_FUNCTIONS src_install pkg_postinst
# @FUNCTION: readme.gentoo_create_doc
# @DESCRIPTION:
# Create doc file with ${DOC_CONTENTS} variable and, if not set,
# with ${FILESDIR}/README.gentoo contents.
# Usually called at src_install phase.
readme.gentoo_create_doc() {
debug-print-function ${FUNCNAME} ${@}
if [[ -n ${DOC_CONTENTS} ]]; then
eshopts_push
set -f
echo ${DOC_CONTENTS} | fmt ${T}/README.gentoo
eshopts_pop
dodoc ${T}/README.gentoo
else
if [[ -f ${FILESDIR}/README.gentoo-${SLOT} ]]; then
cp ${FILESDIR}/README.gentoo-${SLOT} ${T}/README.gentoo
dodoc ${T}/README.gentoo
else
if [[ -f ${FILESDIR}/README.gentoo ]]; then
cp ${FILESDIR}/README.gentoo ${T}/README.gentoo
dodoc ${T}/README.gentoo
else
die You are not specifying README.gentoo contents!
fi
fi
fi
}
# @FUNCTION: readme.gentoo_print_elog
# @DESCRIPTION:
# Print elog messages with ${T}/README.gentoo contents.
# Usually called at pkg_postinst phase.
readme.gentoo_print_elog() {
debug-print-function ${FUNCNAME} ${@}
if [[ -f ${FILESDIR}/README.gentoo-${SLOT} ]]; then
if [[ -f ${T}/README.gentoo ]]; then
if ! [[ ${REPLACING_VERSIONS}:${SLOT} ]]; then
eshopts_push
set -f
cat ${T}/README.gentoo | fmt | while read -r ELINE; do elog ${ELINE}; done
eshopts_pop
fi
else
die README.gentoo wasn't created at src_install!
fi
else
if [[ -f ${T}/README.gentoo ]]; then
if ! [[ ${REPLACING_VERSIONS} ]]; then
eshopts_push
set -f
cat ${T}/README.gentoo | fmt | while read -r ELINE; do elog ${ELINE}; done
eshopts_pop
fi
else
die README.gentoo wasn't created at src_install!
fi
fi
}
# @FUNCTION: readme.gentoo_src_install
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
On 01/13/2013 04:18 AM, Pacho Ramos wrote:
What about this approach?
You should use ${SLOT%/*}, in order to exclude the sub-slot, because you
don't care about the sub-slot and the slash would cause problems.
--
Thanks,
Zac
Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information
El dom, 13-01-2013 a las 04:54 -0800, Zac Medico escribió:
On 01/13/2013 04:18 AM, Pacho Ramos wrote:
What about this approach?
You should use ${SLOT%/*}, in order to exclude the sub-slot, because you
don't care about the sub-slot and the slash would cause problems.
Thanks, updated eclass attached
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: readme.gentoo
# @MAINTAINER:
# Pacho Ramos pa...@gentoo.org
# @AUTHOR:
# Author: Pacho Ramos pa...@gentoo.org
# @BLURB: An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
# @DESCRIPTION:
# An eclass for installing a README.gentoo doc file recording tips
# shown via elog messages. With this eclass, those elog messages will only be
# shown at first package installation and a file for later reviewing will be
# installed under /usr/share/doc/${PF}
if [[ ${___ECLASS_ONCE_README_GENTOO} != recur -_+^+_- spank ]] ; then
___ECLASS_ONCE_README_GENTOO=recur -_+^+_- spank
inherit eutils
case ${EAPI:-0} in
0|1|2|3)
die Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}
;;
4|5)
# EAPI=4 is required for REPLACING_VERSIONS preventing us
# from needing to export another pkg_preinst phase to save has_version
# result. Also relies on EAPI =4 default src_install phase.
;;
*)
die Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}
;;
esac
EXPORT_FUNCTIONS src_install pkg_postinst
# @FUNCTION: readme.gentoo_create_doc
# @DESCRIPTION:
# Create doc file with ${DOC_CONTENTS} variable and, if not set,
# with ${FILESDIR}/README.gentoo contents.
# Usually called at src_install phase.
readme.gentoo_create_doc() {
debug-print-function ${FUNCNAME} ${@}
if [[ -n ${DOC_CONTENTS} ]]; then
eshopts_push
set -f
echo ${DOC_CONTENTS} | fmt ${T}/README.gentoo
eshopts_pop
dodoc ${T}/README.gentoo
else
if [[ -f ${FILESDIR}/README.gentoo-${SLOT%/*} ]]; then
cp ${FILESDIR}/README.gentoo-${SLOT%/*} ${T}/README.gentoo
dodoc ${T}/README.gentoo
else
if [[ -f ${FILESDIR}/README.gentoo ]]; then
cp ${FILESDIR}/README.gentoo ${T}/README.gentoo
dodoc ${T}/README.gentoo
else
die You are not specifying README.gentoo contents!
fi
fi
fi
}
# @FUNCTION: readme.gentoo_print_elog
# @DESCRIPTION:
# Print elog messages with ${T}/README.gentoo contents.
# Usually called at pkg_postinst phase.
readme.gentoo_print_elog() {
debug-print-function ${FUNCNAME} ${@}
if [[ -f ${FILESDIR}/README.gentoo-${SLOT%/*} ]]; then
if [[ -f ${T}/README.gentoo ]]; then
if ! [[ ${REPLACING_VERSIONS}:${SLOT%/*} ]]; then
eshopts_push
set -f
cat ${T}/README.gentoo | fmt | while read -r ELINE; do elog ${ELINE}; done
eshopts_pop
fi
else
die README.gentoo wasn't created at src_install!
fi
else
if [[ -f ${T}/README.gentoo ]]; then
if ! [[ ${REPLACING_VERSIONS} ]]; then
eshopts_push
set -f
cat ${T}/README.gentoo | fmt | while read -r ELINE; do elog ${ELINE}; done
eshopts_pop
fi
else
die README.gentoo wasn't created at src_install!
fi
fi
}
# @FUNCTION: readme.gentoo_src_install
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that will be
# shared with /usr/share/doc/${PF}/README.gentoo content.
readme.gentoo_src_install() {
debug-print-function ${FUNCNAME} ${@}
default
readme.gentoo_create_doc
}
# @FUNCTION: readme.gentoo_pkg_postinst
# @DESCRIPTION:
# Show elog messages from DOC_CONTENTS variable, that will be
# shared with /usr/share/doc/${PF}/README.gentoo content.
readme.gentoo_pkg_postinst() {
debug-print-function ${FUNCNAME} ${@}
readme.gentoo_print_elog
}
fi
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH eutils] Introduce run_in_build_dir() used in a few ebuilds.
The run_in_build_dir() command simply runs given command
in the directory stated as BUILD_DIR. This variable is used commonly
by autotools-utils, cmake-utils and python-r1 eclasses, therefore I'm
proposing adding the relevant function to eutils.
---
gx86/eclass/eutils.eclass | 19 +++
1 file changed, 19 insertions(+)
diff --git a/gx86/eclass/eutils.eclass b/gx86/eclass/eutils.eclass
index 6588792..bb3c1e3 100644
--- a/gx86/eclass/eutils.eclass
+++ b/gx86/eclass/eutils.eclass
@@ -1495,6 +1495,25 @@ prune_libtool_files() {
fi
}
+# @FUNCTION: run_in_build_dir
+# @USAGE: argv...
+# @DESCRIPTION:
+# Run the given command in the directory pointed by BUILD_DIR.
+run_in_build_dir() {
+ debug-print-function ${FUNCNAME} $@
+ local ret
+
+ [[ ${#} -ne 0 ]] || die ${FUNCNAME}: no command specified.
+ [[ ${BUILD_DIR} ]] || die ${FUNCNAME}: BUILD_DIR not set.
+
+ pushd ${BUILD_DIR} /dev/null || die
+ ${@}
+ ret=${?}
+ popd /dev/null || die
+
+ return ${ret}
+}
+
check_license() { die you no longer need this as portage supports
ACCEPT_LICENSE itself; }
fi
--
1.8.1
[gentoo-dev] Lifting the HOMEPAGE requirement for ebuilds
Hello, Right now an attempt to commit an ebuild with no HOMEPAGE results in: HOMEPAGE.missing 1 app-admin/eselect-sh/eselect-sh-0.4.ebuild Note: use --include-dev (-d) to check dependencies for 'dev' profiles Please fix these important QA issues first. Why is this considered an 'important QA issue'? Does the policy really say that if something doesn't have a homepage, we're supposed to put garbage in there? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH eutils] Introduce run_in_build_dir() used in a few ebuilds.
On Sun, Jan 13, 2013 at 02:29:43PM +0100, Michał Górny wrote:
The run_in_build_dir() command simply runs given command
in the directory stated as BUILD_DIR. This variable is used commonly
by autotools-utils, cmake-utils and python-r1 eclasses, therefore I'm
proposing adding the relevant function to eutils.
---
gx86/eclass/eutils.eclass | 19 +++
1 file changed, 19 insertions(+)
diff --git a/gx86/eclass/eutils.eclass b/gx86/eclass/eutils.eclass
index 6588792..bb3c1e3 100644
--- a/gx86/eclass/eutils.eclass
+++ b/gx86/eclass/eutils.eclass
@@ -1495,6 +1495,25 @@ prune_libtool_files() {
fi
}
+# @FUNCTION: run_in_build_dir
+# @USAGE: argv...
+# @DESCRIPTION:
+# Run the given command in the directory pointed by BUILD_DIR.
I think I would make this more generic if it is going in eutiles,
e.g. rename it something like run_in_dir and pass in the directory as the
first argument.
William
pgpxXngvWBzlh.pgp
Description: PGP signature
Re: [gentoo-dev] [PATCH eutils] Introduce run_in_build_dir() used in a few ebuilds.
On Sun, 13 Jan 2013 09:05:31 -0600
William Hubbs willi...@gentoo.org wrote:
On Sun, Jan 13, 2013 at 02:29:43PM +0100, Michał Górny wrote:
The run_in_build_dir() command simply runs given command
in the directory stated as BUILD_DIR. This variable is used commonly
by autotools-utils, cmake-utils and python-r1 eclasses, therefore I'm
proposing adding the relevant function to eutils.
---
gx86/eclass/eutils.eclass | 19 +++
1 file changed, 19 insertions(+)
diff --git a/gx86/eclass/eutils.eclass b/gx86/eclass/eutils.eclass
index 6588792..bb3c1e3 100644
--- a/gx86/eclass/eutils.eclass
+++ b/gx86/eclass/eutils.eclass
@@ -1495,6 +1495,25 @@ prune_libtool_files() {
fi
}
+# @FUNCTION: run_in_build_dir
+# @USAGE: argv...
+# @DESCRIPTION:
+# Run the given command in the directory pointed by BUILD_DIR.
I think I would make this more generic if it is going in eutiles,
e.g. rename it something like run_in_dir and pass in the directory as the
first argument.
That's not going to work for us since the command is subject to a loop
which sets BUILD_DIR, e.g.:
python_foreach_impl run_in_build_dir ...
with python_foreach_impl setting BUILD_DIR.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH eutils] Introduce run_in_build_dir() used in a few ebuilds.
On Sun, Jan 13, 2013 at 5:29 AM, Michał Górny mgo...@gentoo.org wrote:
The run_in_build_dir() command simply runs given command
in the directory stated as BUILD_DIR. This variable is used commonly
by autotools-utils, cmake-utils and python-r1 eclasses, therefore I'm
proposing adding the relevant function to eutils.
---
gx86/eclass/eutils.eclass | 19 +++
1 file changed, 19 insertions(+)
diff --git a/gx86/eclass/eutils.eclass b/gx86/eclass/eutils.eclass
index 6588792..bb3c1e3 100644
--- a/gx86/eclass/eutils.eclass
+++ b/gx86/eclass/eutils.eclass
@@ -1495,6 +1495,25 @@ prune_libtool_files() {
fi
}
+# @FUNCTION: run_in_build_dir
+# @USAGE: argv...
+# @DESCRIPTION:
+# Run the given command in the directory pointed by BUILD_DIR.
+run_in_build_dir() {
+ debug-print-function ${FUNCNAME} $@
+ local ret
local -i ret
?
+
+ [[ ${#} -ne 0 ]] || die ${FUNCNAME}: no command specified.
+ [[ ${BUILD_DIR} ]] || die ${FUNCNAME}: BUILD_DIR not set.
+
+ pushd ${BUILD_DIR} /dev/null || die
+ ${@}
+ ret=${?}
+ popd /dev/null || die
+
+ return ${ret}
+}
+
check_license() { die you no longer need this as portage supports
ACCEPT_LICENSE itself; }
fi
--
1.8.1
Re: [gentoo-dev] [PATCH eutils] Introduce run_in_build_dir() used in a few ebuilds.
Le dimanche 13 janvier 2013 à 16:08 +0100, Michał Górny a écrit :
On Sun, 13 Jan 2013 09:05:31 -0600
William Hubbs willi...@gentoo.org wrote:
On Sun, Jan 13, 2013 at 02:29:43PM +0100, Michał Górny wrote:
The run_in_build_dir() command simply runs given command
in the directory stated as BUILD_DIR. This variable is used commonly
by autotools-utils, cmake-utils and python-r1 eclasses, therefore I'm
proposing adding the relevant function to eutils.
---
gx86/eclass/eutils.eclass | 19 +++
1 file changed, 19 insertions(+)
diff --git a/gx86/eclass/eutils.eclass b/gx86/eclass/eutils.eclass
index 6588792..bb3c1e3 100644
--- a/gx86/eclass/eutils.eclass
+++ b/gx86/eclass/eutils.eclass
@@ -1495,6 +1495,25 @@ prune_libtool_files() {
fi
}
+# @FUNCTION: run_in_build_dir
+# @USAGE: argv...
+# @DESCRIPTION:
+# Run the given command in the directory pointed by BUILD_DIR.
I think I would make this more generic if it is going in eutiles,
e.g. rename it something like run_in_dir and pass in the directory as the
first argument.
That's not going to work for us since the command is subject to a loop
which sets BUILD_DIR, e.g.:
python_foreach_impl run_in_build_dir ...
with python_foreach_impl setting BUILD_DIR.
FTR, this function is used as-is in quite a few gnome ebuilds that use
python-r1 eclass. We thought that it could probably be used in other
places but it would be nice if we could have changes to would make it
not suitable for this purpose.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
Re: [gentoo-dev] [PATCH eutils] Introduce run_in_build_dir() used in a few ebuilds.
On Sun, Jan 13, 2013 at 04:08:18PM +0100, Michał Górny wrote:
On Sun, 13 Jan 2013 09:05:31 -0600
William Hubbs willi...@gentoo.org wrote:
On Sun, Jan 13, 2013 at 02:29:43PM +0100, Michał Górny wrote:
The run_in_build_dir() command simply runs given command
in the directory stated as BUILD_DIR. This variable is used commonly
by autotools-utils, cmake-utils and python-r1 eclasses, therefore I'm
proposing adding the relevant function to eutils.
---
gx86/eclass/eutils.eclass | 19 +++
1 file changed, 19 insertions(+)
diff --git a/gx86/eclass/eutils.eclass b/gx86/eclass/eutils.eclass
index 6588792..bb3c1e3 100644
--- a/gx86/eclass/eutils.eclass
+++ b/gx86/eclass/eutils.eclass
@@ -1495,6 +1495,25 @@ prune_libtool_files() {
fi
}
+# @FUNCTION: run_in_build_dir
+# @USAGE: argv...
+# @DESCRIPTION:
+# Run the given command in the directory pointed by BUILD_DIR.
I think I would make this more generic if it is going in eutiles,
e.g. rename it something like run_in_dir and pass in the directory as the
first argument.
That's not going to work for us since the command is subject to a loop
which sets BUILD_DIR, e.g.:
python_foreach_impl run_in_build_dir ...
Can you not change the logic so it doesn't die if build_dir isn't set,
but uses the value of $1 and calls shift?
Thanks,
William
pgpR5xEg_ZVrc.pgp
Description: PGP signature
Re: [gentoo-dev] [PATCH eutils] Introduce run_in_build_dir() used in a few ebuilds.
On Sun, 13 Jan 2013 09:52:09 -0600
William Hubbs willi...@gentoo.org wrote:
On Sun, Jan 13, 2013 at 04:08:18PM +0100, Michał Górny wrote:
On Sun, 13 Jan 2013 09:05:31 -0600
William Hubbs willi...@gentoo.org wrote:
On Sun, Jan 13, 2013 at 02:29:43PM +0100, Michał Górny wrote:
The run_in_build_dir() command simply runs given command
in the directory stated as BUILD_DIR. This variable is used commonly
by autotools-utils, cmake-utils and python-r1 eclasses, therefore I'm
proposing adding the relevant function to eutils.
---
gx86/eclass/eutils.eclass | 19 +++
1 file changed, 19 insertions(+)
diff --git a/gx86/eclass/eutils.eclass b/gx86/eclass/eutils.eclass
index 6588792..bb3c1e3 100644
--- a/gx86/eclass/eutils.eclass
+++ b/gx86/eclass/eutils.eclass
@@ -1495,6 +1495,25 @@ prune_libtool_files() {
fi
}
+# @FUNCTION: run_in_build_dir
+# @USAGE: argv...
+# @DESCRIPTION:
+# Run the given command in the directory pointed by BUILD_DIR.
I think I would make this more generic if it is going in eutiles,
e.g. rename it something like run_in_dir and pass in the directory as the
first argument.
That's not going to work for us since the command is subject to a loop
which sets BUILD_DIR, e.g.:
python_foreach_impl run_in_build_dir ...
Can you not change the logic so it doesn't die if build_dir isn't set,
but uses the value of $1 and calls shift?
Where? What? I don't follow really. And since I don't follow, I don't
think that's something reasonable to do.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH eutils] Introduce run_in_build_dir() used in a few ebuilds.
On Sun, 13 Jan 2013 07:36:59 -0800
Alec Warner anta...@gentoo.org wrote:
On Sun, Jan 13, 2013 at 5:29 AM, Michał Górny mgo...@gentoo.org wrote:
The run_in_build_dir() command simply runs given command
in the directory stated as BUILD_DIR. This variable is used commonly
by autotools-utils, cmake-utils and python-r1 eclasses, therefore I'm
proposing adding the relevant function to eutils.
---
gx86/eclass/eutils.eclass | 19 +++
1 file changed, 19 insertions(+)
diff --git a/gx86/eclass/eutils.eclass b/gx86/eclass/eutils.eclass
index 6588792..bb3c1e3 100644
--- a/gx86/eclass/eutils.eclass
+++ b/gx86/eclass/eutils.eclass
@@ -1495,6 +1495,25 @@ prune_libtool_files() {
fi
}
+# @FUNCTION: run_in_build_dir
+# @USAGE: argv...
+# @DESCRIPTION:
+# Run the given command in the directory pointed by BUILD_DIR.
+run_in_build_dir() {
+ debug-print-function ${FUNCNAME} $@
+ local ret
local -i ret
?
Looks good. I didn't even know bash has something like that.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH eutils] Introduce run_in_build_dir() used in a few ebuilds.
Le dimanche 13 janvier 2013 à 09:52 -0600, William Hubbs a écrit :
On Sun, Jan 13, 2013 at 04:08:18PM +0100, Michał Górny wrote:
On Sun, 13 Jan 2013 09:05:31 -0600
William Hubbs willi...@gentoo.org wrote:
On Sun, Jan 13, 2013 at 02:29:43PM +0100, Michał Górny wrote:
The run_in_build_dir() command simply runs given command
in the directory stated as BUILD_DIR. This variable is used commonly
by autotools-utils, cmake-utils and python-r1 eclasses, therefore I'm
proposing adding the relevant function to eutils.
---
gx86/eclass/eutils.eclass | 19 +++
1 file changed, 19 insertions(+)
diff --git a/gx86/eclass/eutils.eclass b/gx86/eclass/eutils.eclass
index 6588792..bb3c1e3 100644
--- a/gx86/eclass/eutils.eclass
+++ b/gx86/eclass/eutils.eclass
@@ -1495,6 +1495,25 @@ prune_libtool_files() {
fi
}
+# @FUNCTION: run_in_build_dir
+# @USAGE: argv...
+# @DESCRIPTION:
+# Run the given command in the directory pointed by BUILD_DIR.
I think I would make this more generic if it is going in eutiles,
e.g. rename it something like run_in_dir and pass in the directory as the
first argument.
That's not going to work for us since the command is subject to a loop
which sets BUILD_DIR, e.g.:
python_foreach_impl run_in_build_dir ...
Can you not change the logic so it doesn't die if build_dir isn't set,
but uses the value of $1 and calls shift?
I guess an explicit option would be less error prone, eg. :
run_in_dir -d foodir barfunc arg1 arg2
or
run_in_dir --directory foodir barfunc arg1 arg2
documentation could then mention that the function defaults to BUILD_DIR
if this option is not set and fails if nothing is set.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
[gentoo-dev] Re: Lifting the HOMEPAGE requirement for ebuilds
Michał Górny posted on Sun, 13 Jan 2013 15:24:02 +0100 as excerpted: Hello, Right now an attempt to commit an ebuild with no HOMEPAGE results in: HOMEPAGE.missing 1 app-admin/eselect-sh/eselect-sh-0.4.ebuild Note: use --include-dev (-d) to check dependencies for 'dev' profiles Please fix these important QA issues first. Why is this considered an 'important QA issue'? Does the policy really say that if something doesn't have a homepage, we're supposed to put garbage in there? How does something not have a homepage? If upstream is gone, then by definition, gentoo's the upstream as we're distributing it, so gentoo.org becomes the homepage. (I've always thought there should be a special page for this purpose on the gentoo site, more or less like the package version of a 404 error, explaining that for this package upstream is dead, so as the distributor, we're now the homepage, that would distinguish this case from proper gentoo projects and avoid this question coming up occasionally as it seems to, but...) -- 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
Re: [gentoo-dev] Lifting the HOMEPAGE requirement for ebuilds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/13/2013 03:24 PM, Michał Górny wrote: Hello, Right now an attempt to commit an ebuild with no HOMEPAGE results in: HOMEPAGE.missing 1 app-admin/eselect-sh/eselect-sh-0.4.ebuild Note: use --include-dev (-d) to check dependencies for 'dev' profiles Please fix these important QA issues first. Why is this considered an 'important QA issue'? Does the policy really say that if something doesn't have a homepage, we're supposed to put garbage in there? That is already lifted: https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-660007.2 seems to be a repoman bug or just not yet implemented -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQ8vI7AAoJEFpvPKfnPDWzv8kIAKD2+Uuy/u22UrOOnQoMtnqn VzaeuSXzrNTptbHJ7ywlyD54G7YHzdf9oQwnFbZENmR8tGywZbdaIK4bX27Muq9v rBN+jiE1yKbOWGdYFcppCsculveB2xi5DbkLu8iqj0jL+DYDumTQU0ILXGJfEgR7 EiCIohxXjTsz8XveNesnlR6u2ZwjzZsN45lXX7VhwP03QfhzstffIHG3na8+lXkB BUZNFgVIjrEvtZy03Ge/ieh5dvdQ3NR6+mxi5mcoKpl0pdj0M1j/4DiS82tRY2sz rQGNyvI2jIkS+WL+MwIJAjDVNeNeycOhL70m4do2IkTuTqBEoN74WmvVVWvbCwc= =va+r -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Lifting the HOMEPAGE requirement for ebuilds
On Sun, 13 Jan 2013 17:33:27 + (UTC) Duncan 1i5t5.dun...@cox.net wrote: Michał Górny posted on Sun, 13 Jan 2013 15:24:02 +0100 as excerpted: Hello, Right now an attempt to commit an ebuild with no HOMEPAGE results in: HOMEPAGE.missing 1 app-admin/eselect-sh/eselect-sh-0.4.ebuild Note: use --include-dev (-d) to check dependencies for 'dev' profiles Please fix these important QA issues first. Why is this considered an 'important QA issue'? Does the policy really say that if something doesn't have a homepage, we're supposed to put garbage in there? How does something not have a homepage? If upstream is gone, then by definition, gentoo's the upstream as we're distributing it, so gentoo.org becomes the homepage. If something is a six-liner made by Gentoo and for Gentoo, noone cares enough to create a homepage for it. http://gentoo.org is the most useless 'homepage' value you can use. It doesn't mean anything, and especially you aren't going to find a piece of information on the software on that site. In that case, even https://bugs.gentoo.org is more useful. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Lifting the HOMEPAGE requirement for ebuilds
On 01/13/2013 09:43 AM, hasufell wrote: On 01/13/2013 03:24 PM, Michał Górny wrote: Hello, Right now an attempt to commit an ebuild with no HOMEPAGE results in: HOMEPAGE.missing 1 app-admin/eselect-sh/eselect-sh-0.4.ebuild Note: use --include-dev (-d) to check dependencies for 'dev' profiles Please fix these important QA issues first. Why is this considered an 'important QA issue'? Does the policy really say that if something doesn't have a homepage, we're supposed to put garbage in there? That is already lifted: https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-660007.2 seems to be a repoman bug or just not yet implemented repoman is intended to enforce policies, which can be stricter than pms. So, the question is, what is our policy going to be? -- Thanks, Zac
Re: [gentoo-dev] Lifting the HOMEPAGE requirement for ebuilds
On 01/13/2013 07:03 PM, Zac Medico wrote: On 01/13/2013 09:43 AM, hasufell wrote: On 01/13/2013 03:24 PM, Michał Górny wrote: Hello, Right now an attempt to commit an ebuild with no HOMEPAGE results in: HOMEPAGE.missing 1 app-admin/eselect-sh/eselect-sh-0.4.ebuild Note: use --include-dev (-d) to check dependencies for 'dev' profiles Please fix these important QA issues first. Why is this considered an 'important QA issue'? Does the policy really say that if something doesn't have a homepage, we're supposed to put garbage in there? That is already lifted: https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-660007.2 seems to be a repoman bug or just not yet implemented repoman is intended to enforce policies, which can be stricter than pms. So, the question is, what is our policy going to be? +1 to allow empty/missing HOMEPAGE variable dead homepage = useless http://gentoo.org = useless https://bugs.gentoo.org = too obvious
Re: [gentoo-dev] Lifting the HOMEPAGE requirement for ebuilds
On Sunday 13 January 2013 09:24:02 Michał Górny wrote: Right now an attempt to commit an ebuild with no HOMEPAGE results in: HOMEPAGE.missing 1 app-admin/eselect-sh/eselect-sh-0.4.ebuild use the common eselect homepage ? http://www.gentoo.org/proj/en/eselect/ -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH eutils] Introduce run_in_build_dir() used in a few ebuilds.
On Sunday 13 January 2013 08:29:43 Michał Górny wrote:
+ [[ ${BUILD_DIR} ]] || die ${FUNCNAME}: BUILD_DIR not set.
really should use -n there
+ pushd ${BUILD_DIR} /dev/null || die
+ popd /dev/null || die
sending errors to /dev/null is wrong
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Lifting the HOMEPAGE requirement for ebuilds
On Sun, 13 Jan 2013 13:27:02 -0500 Mike Frysinger vap...@gentoo.org wrote: On Sunday 13 January 2013 09:24:02 Michał Górny wrote: Right now an attempt to commit an ebuild with no HOMEPAGE results in: HOMEPAGE.missing 1 app-admin/eselect-sh/eselect-sh-0.4.ebuild use the common eselect homepage ? http://www.gentoo.org/proj/en/eselect/ How is it meaningful? It would suggest people to look for something there... and there's nothing about eselect-sh there. If the only purpose of HOMEPAGE is to put something semi-related there, I think it should be renamed to SEMIRANDOMURI. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Lifting the HOMEPAGE requirement for ebuilds
On Sunday 13 January 2013 13:27:44 Michał Górny wrote: On Sun, 13 Jan 2013 13:27:02 -0500 Mike Frysinger vap...@gentoo.org wrote: On Sunday 13 January 2013 09:24:02 Michał Górny wrote: Right now an attempt to commit an ebuild with no HOMEPAGE results in: HOMEPAGE.missing 1 app-admin/eselect-sh/eselect-sh-0.4.ebuild use the common eselect homepage ? http://www.gentoo.org/proj/en/eselect/ How is it meaningful? It would suggest people to look for something there... and there's nothing about eselect-sh there. If the only purpose of HOMEPAGE is to put something semi-related there, I think it should be renamed to SEMIRANDOMURI. have you actually read the page ? there is general eselect guides and overviews. conversely, i install eselect-sh and then what ? it provides absolutely no documentation -- an sh.eselect file with no information as how to use it. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Lifting the HOMEPAGE requirement for ebuilds
On Sun, 13 Jan 2013 13:33:49 -0500 Mike Frysinger vap...@gentoo.org wrote: On Sunday 13 January 2013 13:27:44 Michał Górny wrote: On Sun, 13 Jan 2013 13:27:02 -0500 Mike Frysinger vap...@gentoo.org wrote: On Sunday 13 January 2013 09:24:02 Michał Górny wrote: Right now an attempt to commit an ebuild with no HOMEPAGE results in: HOMEPAGE.missing 1 app-admin/eselect-sh/eselect-sh-0.4.ebuild use the common eselect homepage ? http://www.gentoo.org/proj/en/eselect/ How is it meaningful? It would suggest people to look for something there... and there's nothing about eselect-sh there. If the only purpose of HOMEPAGE is to put something semi-related there, I think it should be renamed to SEMIRANDOMURI. have you actually read the page ? there is general eselect guides and overviews. conversely, i install eselect-sh and then what ? it provides absolutely no documentation -- an sh.eselect file with no information as how to use it. Ok, that is an argument. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Lifting the HOMEPAGE requirement for ebuilds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/13/2013 12:58 PM, Michał Górny wrote: If something is a six-liner made by Gentoo and for Gentoo, noone cares enough to create a homepage for it. http://gentoo.org is the most useless 'homepage' value you can use. It doesn't mean anything, and especially you aren't going to find a piece of information on the software on that site. In that case, even https://bugs.gentoo.org is more useful. My most common use for the HOMEPAGE is when I'm looking through eix output wondering WTF does this do? So I visit the homepage to find out. Even for a six-line script, you should have the time to essentially `echo README index.html` and upload it somewhere. This at least lets people click on the URL, see what the package does, and find out where to report bugs. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJQ8v4pAAoJEBxJck0inpOiQuEP/RYcdAAPyEaxn82D4IpKQfow 7PK2093inRZtXwdXGw7Ijg00wurgW50panrJ2pWExmwXvSvZddY3wDGXpypW9W+C YcVk7JuAPvUAM5MUkRhWqlIc/ifDpLc7fsXpcT9yUp9phpbMHCLNmXTSEAm1MWhS 0dhzHDqr7UySwjxRLtoL3xnb2xYVHtUy1XMRIICl45FbLPBqB3ZQCi/jDEFILEqA +Y9LJTV1a+RGoT97SbQfSbSyFeMAOG1o9LPuDUrYzRMhYeFQDVsUQG+ek2UOvF5q V8usQnx69P7s+yl4PUTKQ33nINZonKYTg3XOVuEgv/ZZGwx3ddZAOhfrNczkHdWk ZMf62RaN8NRRK97Jid9WnLk7MGN2IdeABgHegqbRtIb3+yi57/JLvONMx1zFOtCp y0fBgL+sBF3UhKEfGHgj8iy3prWUdVFizK1rgBIB2tPUzht5uM1RC5VYW7QOpID9 syMGm3b22wVEtmcgw7Kqn7Dam+R/QGSGcJsbNRFIdslzwyrEaqNbTcsYK1qwBCfH iOekrGYE8GyIWF3z8yopkgErLl4S+0lRTuQ9T1nwetP3OaJLPn71r6Rn24DgJjeb xKEkR+Sbn17pooXIkW4idaPw9YhwP7FyGxpmvF1wRKFG/nE5Bh/bC2D+qqq5JbTt 44nxXjaTEsRuh8jjmcbp =gcv7 -END PGP SIGNATURE-
[gentoo-dev] [PATCH 0/4] gnome2.eclass updates
Hi list, here are a couple of patches to fix some bad behavior of the gnome2.eclass. They have been sitting in the overlay for a while and I don't expect them to cause any problem so I will commit then later today if nobody objects. Gilles Dartiguelongue (4): eclass/gnome2.eclass: switch IUSE tests to in_iuse, bug #383901 eclass/gnome2.eclass: drop deprecated SCROLLKEEPER_UPDATE eclass/gnome2.eclass: allow ebuild override of eclass generated econf eclass/gnome2.eclass: update wrt comment on bug #383901 eclass/gnome2.eclass | 28 +++- 1 file changed, 11 insertions(+), 17 deletions(-) -- 1.8.1 -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH 1/4] switch IUSE tests to in_iuse, bug #383901
has bla ${IUSE} is standardized through in_iuse. Make use of this function.
---
eclass/gnome2.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/gnome2.eclass b/eclass/gnome2.eclass
index 70eb491..e263232 100644
--- a/eclass/gnome2.eclass
+++ b/eclass/gnome2.eclass
@@ -158,7 +158,7 @@ gnome2_src_configure() {
# rebuild docs.
# Preserve old behavior for older EAPI.
if grep -q enable-gtk-doc ${ECONF_SOURCE:-.}/configure ; then
- if has ${EAPI-0} 0 1 2 3 4 has doc ${IUSE} ; then
+ if has ${EAPI:-0} 0 1 2 3 4 in_iuse doc ; then
G2CONF=${G2CONF} $(use_enable doc gtk-doc)
else
G2CONF=${G2CONF} --disable-gtk-doc
@@ -266,7 +266,7 @@ gnome2_src_install() {
if has ${EAPI:-0} 0 1 2 3 4; then
if [[ ${GNOME2_LA_PUNT} != no ]]; then
ebegin Removing .la files
- if ! { has static-libs ${IUSE//+} use static-libs;
}; then
+ if ! { in_iuse static-libs use static-libs; }; then
find ${D} -name '*.la' -exec rm -f {} + ||
die la file removal failed
fi
eend
--
1.8.1
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH 2/4] drop deprecated SCROLLKEEPER_UPDATE
SCROLLKEEPER_UPDATE variable was deprecated long ago. It is no longer needed
and no longer in use in tree.
---
eclass/gnome2.eclass | 6 --
1 file changed, 6 deletions(-)
diff --git a/eclass/gnome2.eclass b/eclass/gnome2.eclass
index e263232..e2540d1 100644
--- a/eclass/gnome2.eclass
+++ b/eclass/gnome2.eclass
@@ -68,12 +68,6 @@ ELTCONF=${ELTCONF:-}
# Should we use EINSTALL instead of DESTDIR
USE_EINSTALL=${USE_EINSTALL:-}
-# @ECLASS-VARIABLE: SCROLLKEEPER_UPDATE
-# @DEPRECATED
-# @DESCRIPTION:
-# Whether to run scrollkeeper for this package or not.
-SCROLLKEEPER_UPDATE=${SCROLLKEEPER_UPDATE:-1}
-
# @ECLASS-VARIABLE: DOCS
# @DEFAULT-UNSET
# @DESCRIPTION:
--
1.8.1
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH 3/4] allow ebuild override of eclass generated econf
gnome2.eclass appends configure switches to user arguments.
Change logic so that it prepends values to G2CONF and pass extra args
of
gnome2_src_configure after G2CONF so that ebuilds can indeed override
eclass
settings.
---
eclass/gnome2.eclass | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/eclass/gnome2.eclass b/eclass/gnome2.eclass
index e2540d1..750f20b 100644
--- a/eclass/gnome2.eclass
+++ b/eclass/gnome2.eclass
@@ -140,7 +140,7 @@ gnome2_src_configure() {
# Update the GNOME configuration options
if [[ ${GCONF_DEBUG} != 'no' ]] ; then
if use debug ; then
- G2CONF=${G2CONF} --enable-debug=yes
+ G2CONF=--enable-debug=yes ${G2CONF}
fi
fi
@@ -153,44 +153,44 @@ gnome2_src_configure() {
# Preserve old behavior for older EAPI.
if grep -q enable-gtk-doc ${ECONF_SOURCE:-.}/configure ; then
if has ${EAPI:-0} 0 1 2 3 4 in_iuse doc ; then
- G2CONF=${G2CONF} $(use_enable doc gtk-doc)
+ G2CONF=$(use_enable doc gtk-doc) ${G2CONF}
else
- G2CONF=${G2CONF} --disable-gtk-doc
+ G2CONF=--disable-gtk-doc ${G2CONF}
fi
fi
# Pass --disable-maintainer-mode when needed
if grep -q ^[[:space:]]*AM_MAINTAINER_MODE(\[enable\]) \
${ECONF_SOURCE:-.}/configure.*; then
- G2CONF=${G2CONF} --disable-maintainer-mode
+ G2CONF=--disable-maintainer-mode ${G2CONF}
fi
# Pass --disable-scrollkeeper when possible
if grep -q disable-scrollkeeper ${ECONF_SOURCE:-.}/configure; then
- G2CONF=${G2CONF} --disable-scrollkeeper
+ G2CONF=--disable-scrollkeeper ${G2CONF}
fi
# Pass --disable-silent-rules when possible (not needed for eapi5),
bug #429308
if has ${EAPI:-0} 0 1 2 3 4; then
if grep -q disable-silent-rules ${ECONF_SOURCE:-.}/configure;
then
- G2CONF=${G2CONF} --disable-silent-rules
+ G2CONF=--disable-silent-rules ${G2CONF}
fi
fi
# Pass --disable-schemas-install when possible
if grep -q disable-schemas-install ${ECONF_SOURCE:-.}/configure;
then
- G2CONF=${G2CONF} --disable-schemas-install
+ G2CONF=--disable-schemas-install ${G2CONF}
fi
# Pass --disable-schemas-compile when possible
if grep -q disable-schemas-compile ${ECONF_SOURCE:-.}/configure;
then
- G2CONF=${G2CONF} --disable-schemas-compile
+ G2CONF=--disable-schemas-compile ${G2CONF}
fi
# Avoid sandbox violations caused by gnome-vfs (bug #128289 and
#345659)
addwrite $(unset HOME; echo ~)/.gnome2
- econf $@ ${G2CONF}
+ econf ${G2CONF} $@
}
# @FUNCTION: gnome2_src_compile
--
1.8.1
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH 4/4] update wrt comment on bug #383901
Update previous patch fixing bug #383901 with comments on this bug.
---
eclass/gnome2.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/gnome2.eclass b/eclass/gnome2.eclass
index 750f20b..592585c 100644
--- a/eclass/gnome2.eclass
+++ b/eclass/gnome2.eclass
@@ -260,7 +260,7 @@ gnome2_src_install() {
if has ${EAPI:-0} 0 1 2 3 4; then
if [[ ${GNOME2_LA_PUNT} != no ]]; then
ebegin Removing .la files
- if ! { in_iuse static-libs use static-libs; }; then
+ if ! use_if_iuse static-libs ; then
find ${D} -name '*.la' -exec rm -f {} + ||
die la file removal failed
fi
eend
--
1.8.1
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 1/4] switch IUSE tests to in_iuse, bug #383901
On Sun, 13 Jan 2013 20:03:20 +0100
Gilles Dartiguelongue e...@gentoo.org wrote:
- if has ${EAPI-0} 0 1 2 3 4 has doc ${IUSE} ; then
+ if has ${EAPI:-0} 0 1 2 3 4 in_iuse doc ; then
This is still wrong... You can't use IUSE like that.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH 1/4] switch IUSE tests to in_iuse, bug #383901
On Sun, 13 Jan 2013 19:09:05 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Sun, 13 Jan 2013 20:03:20 +0100
Gilles Dartiguelongue e...@gentoo.org wrote:
- if has ${EAPI-0} 0 1 2 3 4 has doc ${IUSE} ; then
+ if has ${EAPI:-0} 0 1 2 3 4 in_iuse doc ; then
This is still wrong... You can't use IUSE like that.
We missed you!
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH 1/4] switch IUSE tests to in_iuse, bug #383901
Le dimanche 13 janvier 2013 à 19:09 +, Ciaran McCreesh a écrit :
On Sun, 13 Jan 2013 20:03:20 +0100
Gilles Dartiguelongue e...@gentoo.org wrote:
- if has ${EAPI-0} 0 1 2 3 4 has doc ${IUSE} ; then
+ if has ${EAPI:-0} 0 1 2 3 4 in_iuse doc ; then
This is still wrong... You can't use IUSE like that.
I think this debate has already happened on this very list.
I don't presently want to fix your particular issues with that solution
but at the very least we can use the same hack (if you will)
everywhere so it is more easy to search for and eventually fix later on.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
Re: [gentoo-dev] [PATCH 1/4] switch IUSE tests to in_iuse, bug #383901
On Sun, 13 Jan 2013 20:35:59 +0100
Gilles Dartiguelongue e...@gentoo.org wrote:
Le dimanche 13 janvier 2013 à 19:09 +, Ciaran McCreesh a écrit :
On Sun, 13 Jan 2013 20:03:20 +0100
Gilles Dartiguelongue e...@gentoo.org wrote:
- if has ${EAPI-0} 0 1 2 3 4 has doc ${IUSE} ;
then
+ if has ${EAPI:-0} 0 1 2 3 4 in_iuse doc ; then
This is still wrong... You can't use IUSE like that.
I think this debate has already happened on this very list.
Yes, it has, and the conclusion was that in_iuse was not to be used in
the way that you're using it.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: Lifting the HOMEPAGE requirement for ebuilds
On Sun, 13 Jan 2013, Michał Górny wrote: How does something not have a homepage? If upstream is gone, then by definition, gentoo's the upstream as we're distributing it, so gentoo.org becomes the homepage. If something is a six-liner made by Gentoo and for Gentoo, noone cares enough to create a homepage for it. Then you could use your project page, or the gitweb of the repo. Or create a wiki page, this doesn't take more than ten minutes. http://gentoo.org is the most useless 'homepage' value you can use. It doesn't mean anything, and especially you aren't going to find a piece of information on the software on that site. It is still better than leaving the field empty, even if its only meaning is Gentoo is upstream for this package. And I'm sure that in most cases a better homepage can be found. Ulrich
Re: [gentoo-dev] Re: call for testers: udev predictable network interface names
but again it appears that simple cases are being made complex, just to allow for someone else's complex cases. Which is faulty logic. It's a welcome option but an important question seems to be; Why wasn't this picked up in the dev cycle?. This reminds me of udisks 8 months ago losing features for multi-seat costing me time to replace it with udev and scripts which I still prefer. Is it coincidence that Redhat wanted complex multiseat at all costs for udisks and Redhat want fast boot at all cost for cloud services? p.s. I am very glad of RedHats contributions and respect their position of giving coders freedom but I just think that if they are able to fund coders to look after a corner full-time or completely then they need to manage that corner or atleast have some ground rules to cover any case of my way or the high way. The kernel wouldn't tolerate this kind of breakage and I really hope I never see linux userland as dependent on IPC as minix is or as broken without IPC as windows is without RPC. I take the unarguably more secure well setup sudoers and useful small tools anyone can use or take code from over polkit anyday. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-01-13 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2013-01-13 23h59 UTC. Removals: dev-haskell/time2013-01-11 22:11:52 slyfox app-emulation/qemulator 2013-01-12 07:49:01 cardoe app-admin/webalizer-xtended 2013-01-13 14:23:05 blueness Additions: x11-misc/dex2013-01-07 23:10:55 pinkbyte media-fonts/fifth-leg 2013-01-08 14:44:01 miska dev-python/py-amqp 2013-01-08 21:47:09 iksaif dev-python/flask-login 2013-01-08 22:21:55 zx2c4 dev-ruby/metasploit_data_models 2013-01-09 02:27:58 zerochaos dev-vcs/hub 2013-01-10 04:09:49 ottxor dev-ruby/robots 2013-01-10 04:23:23 zerochaos dev-perl/Quota 2013-01-11 10:41:37 dev-zero dev-perl/File-Copy-Link 2013-01-11 10:42:33 dev-zero dev-perl/UUID-Tiny 2013-01-11 10:43:02 dev-zero www-apps/webdavcgi 2013-01-11 10:43:38 dev-zero dev-tex/minted 2013-01-11 14:40:46 jlec app-crypt/loop-aes-losetup 2013-01-11 16:48:57 alonbl sys-fs/reiserfs-defrag 2013-01-12 17:10:08 pinkbyte sys-apps/apply-default-acl 2013-01-13 01:04:50 pinkbyte sci-mathematics/cado-nfs2013-01-13 10:44:54 patrick app-admin/eselect-lib-bin-symlink 2013-01-13 14:15:11 mgorny app-vim/sleuth 2013-01-13 18:41:05 radhermit app-vim/voom2013-01-13 19:04:02 radhermit app-portage/fquery 2013-01-13 20:09:43 slyfox -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: dev-haskell/time,removed,slyfox,2013-01-11 22:11:52 app-emulation/qemulator,removed,cardoe,2013-01-12 07:49:01 app-admin/webalizer-xtended,removed,blueness,2013-01-13 14:23:05 Added Packages: x11-misc/dex,added,pinkbyte,2013-01-07 23:10:55 media-fonts/fifth-leg,added,miska,2013-01-08 14:44:01 dev-python/py-amqp,added,iksaif,2013-01-08 21:47:09 dev-python/flask-login,added,zx2c4,2013-01-08 22:21:55 dev-ruby/metasploit_data_models,added,zerochaos,2013-01-09 02:27:58 dev-vcs/hub,added,ottxor,2013-01-10 04:09:49 dev-ruby/robots,added,zerochaos,2013-01-10 04:23:23 dev-perl/Quota,added,dev-zero,2013-01-11 10:41:37 dev-perl/File-Copy-Link,added,dev-zero,2013-01-11 10:42:33 dev-perl/UUID-Tiny,added,dev-zero,2013-01-11 10:43:02 www-apps/webdavcgi,added,dev-zero,2013-01-11 10:43:38 dev-tex/minted,added,jlec,2013-01-11 14:40:46 app-crypt/loop-aes-losetup,added,alonbl,2013-01-11 16:48:57 sys-fs/reiserfs-defrag,added,pinkbyte,2013-01-12 17:10:08 sys-apps/apply-default-acl,added,pinkbyte,2013-01-13 01:04:50 sci-mathematics/cado-nfs,added,patrick,2013-01-13 10:44:54 app-admin/eselect-lib-bin-symlink,added,mgorny,2013-01-13 14:15:11 app-vim/sleuth,added,radhermit,2013-01-13 18:41:05 app-vim/voom,added,radhermit,2013-01-13 19:04:02 app-portage/fquery,added,slyfox,2013-01-13 20:09:43 Done.
Re: [gentoo-dev] app-emulation/qemu-user mask
Hi! For cross-chroots its needed to have static qemu-$arch user translators. May be you can introduce user-static use flag for them? Also it will be cool to have init script for kvm В письме от 11 января 2013 22:45:30 пользователь Doug Goldstein написал: Just wanted to give everyone a heads up. app-emulation/qemu provides all the functionality of app-emulation/qemu-user without all the outstanding security bugs and issues the package has. For users using a cross chroot, I encourage you to look at QEMU_USER_TARGETS. I presently use an arm chroot with app-emulation/qemu. Should there truly be a missing feature, open a bug and I'll fix it. The only item I'm aware of that app-emulation/qemu does not have is the binfmt initscript. But I plan on adding that to the unstable version shortly. If there are no objections for 30 days, I'll send a treecleaner notice in 30 days and remove it 30 days after that (60 days from now).
[gentoo-dev] Re: Re: call for testers: udev predictable network interface names
On Sat, Jan 12, 2013 William Hubbs wrote: Steven J. Long wrote: Obviously it's good to have the functionality should you need it, but again it appears that simple cases are being made complex, just to allow for someone else's complex cases. Which is faulty logic. While many packages have default configurations, changing the default setup for base system packages in the absence of any configuration is not generally a good idea, unless you know for a fact it's not going to mess anything up (which is a big ask given that you're distributing source.) Especially given the arguments presented as a motivation, that all this has serious security implications, for example in firewall rules which are coded for certain naming schemes, and which are hence very sensitive to unpredictable changing names. Isn't this the very definition of the kernel-based names? Not if you read what Christopher wrote in his reply to you: Christopher Head wrote: But given a simple computer with just one NIC, if the NIC fails and is replaced (perhaps by a different type of NIC in a different slot, or perhaps an onboard NIC disabled in the BIOS and replaced by an add-in), the name could change, while the kernel's automatically assigned name will not: eth0 (this also applies to a computer with one Ethernet NIC and one wifi NIC: eth0 and wlan0). That fact was never mentioned on the wiki. Amazingly convenient. Anyone would think the kernel devs had gone through this themselves! ;) IME that setup describes pretty much every end-user desktop or laptop computer I've come across, except the *very* occasional analyst with 2 NICs, and users I don't count as end-users-- in whose name all the awful hackage is supposedly carried out. if you do not have a persistent net rules file, you are subject to the kernel's naming order, and I have heard of situations in the past when people upgrade their kernels, etc, and when they reboot their interface names are changed around. Yes, I've heard of that too, and I'm all for giving them the ability to set things up exactly how they like, just like I've always been in favour of an initrd *if* you need it (or are a binary distro.) Granted that's always meant encrypted rootfs to me, but a bluetooth keyboard is just as valid: it's the user's choice/system, give them what they need to set it up and run it (and leave you alone.) What I'm not in favour of is making the simple cases more difficult, to deal with the complex ones. It's completely brain-dead thinking. More importantly, advances in the code don't change the principle: you don't break backward compatibility for a default install; you don't require people to opt into anything in order to keep their existing config running, MOST especially if they have not even tweaked anything. You put out the last version, so if something's not supported in the new one, you write code to handle the change gracefully, if it's needed. Or you get a well-earnt basting. I guess in distro context you have to allow: unless it's a whole new package, or at worst a major version change. But the principle still applies, *more* stringently to a coder than a distro packager, irrespective of how people learning nowadays might carry on. Or just give up any pretence of caring about your users (and where I come from, the majority of the pay that you nearly burnt-out to earn, since you have to cover another 2 or 3 months of remedial work caused by your own stupidity.) If you're certain that every user with a current simple setup, who uses the kernel default names, and has such a firewall setup isn't going to suddenly find their interface name changed when they reboot, fair play to you. If not, allow the admin to opt-in, rather than force them to opt-out when something breaks. The following is taken from the wiki: You basically have three options: 3 options that all require an admin opt-in to keep their existing config running There you go: the exact wrong way to do it. As Poettering might say: C'mon man, seriously? (whiny voice and pleading looks) Honestly, the guy's a complete amateur. -- #friendly-coders -- Where you can unwind when some nub starts throwing the word integration around.
[gentoo-dev] Re: Re: call for testers: udev predictable network interface names
Kevin Chadwick wrote: but again it appears that simple cases are being made complex, just to allow for someone else's complex cases. Which is faulty logic. It's a welcome option but an important question seems to be; Why wasn't this picked up in the dev cycle?. That would require consequences when borkage was put out, beyond just releasing new binaries. Something like having to go and personally reboot and reconfigure all the hosts that didn't work because of the lack of thinking. The kernel wouldn't tolerate this kind of breakage Exactly. Or imagine glibc requiring coders to do even a half of what end-users and admins have had to go through to get their machines working after Lennart's pressed enter. and I really hope I never see linux userland as dependent on IPC as minix is or as broken without IPC as windows is without RPC. I take the unarguably more secure well setup sudoers and useful small tools anyone can use or take code from over polkit anyday. Yeah, and PAM is a lovely invention. Dominique, who does a lot of the work on pro-audio overlay, saved me from nubkit thankfully[1]- it even makes things faster for some reason, which wasn't at all why I went ahead with it. Nothing like the speedup from losing semantic-craptop, of course. 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) Do the simplest thing that could possibly work. First make it work. Then make it work right. Then make it faster. My all time favourite: When in doubt, use brute force. Thompson Regards, steveL. [1] *kit free system [lxde kde gnome-2.32] http://forums.gentoo.org/viewtopic-p-7171240.html -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] app-emulation/qemu-user mask
On Sun, Jan 13, 2013 at 1:45 PM, Alexey Shvetsov ale...@gentoo.org wrote: Hi! For cross-chroots its needed to have static qemu-$arch user translators. May be you can introduce user-static use flag for them? Also it will be cool to have init script for kvm USE=static is available for app-emulation/qemu. I'll get a chroot for arm setup soon and test everything to make sure its working well. With regards to the KVM init script, I'm uninterested in maintaining it and it doesn't belong in the package as it is. There's a number of submitted init scripts that are attempting to create init scripts but really they're re-inventing libvirt and ganeti, but instead poorly. Ones I know about are: https://bugs.gentoo.org/show_bug.cgi?id=321517 https://bugs.gentoo.org/show_bug.cgi?id=406043 -- Doug Goldstein
Re: [gentoo-dev] app-emulation/qemu-user mask
В письме от 14 января 2013 00:38:06 пользователь Doug Goldstein написал: On Sun, Jan 13, 2013 at 1:45 PM, Alexey Shvetsov ale...@gentoo.org wrote: Hi! For cross-chroots its needed to have static qemu-$arch user translators. May be you can introduce user-static use flag for them? Also it will be cool to have init script for kvm USE=static is available for app-emulation/qemu. I'll get a chroot for arm setup soon and test everything to make sure its working well. It doesnt allow to build dynamik qemu-system* and static user targets With regards to the KVM init script, I'm uninterested in maintaining it and it doesn't belong in the package as it is. There's a number of submitted init scripts that are attempting to create init scripts but really they're re-inventing libvirt and ganeti, but instead poorly. Ones I know about are: https://bugs.gentoo.org/show_bug.cgi?id=321517 https://bugs.gentoo.org/show_bug.cgi?id=406043 Ghm.. Its some kind of overkill to install libvirt or gannety just for 1-2 vms
Re: [gentoo-dev] app-emulation/qemu-user mask
On Mon, 2013-01-14 at 00:38 -0600, Doug Goldstein wrote: On Sun, Jan 13, 2013 at 1:45 PM, Alexey Shvetsov ale...@gentoo.org wrote: Hi! For cross-chroots its needed to have static qemu-$arch user translators. May be you can introduce user-static use flag for them? Also it will be cool to have init script for kvm USE=static is available for app-emulation/qemu. I'll get a chroot for arm setup soon and test everything to make sure its working well. With regards to the KVM init script, I'm uninterested in maintaining it and it doesn't belong in the package as it is. There's a number of submitted init scripts that are attempting to create init scripts but really they're re-inventing libvirt and ganeti, but instead poorly. Ones I know about are: https://bugs.gentoo.org/show_bug.cgi?id=321517 https://bugs.gentoo.org/show_bug.cgi?id=406043 There is a kvm/qemu init script system in the qemu-init overlay available in layman layman -a qemu-init emerge app-emulation/qemu-init-scripts It can handle most kvm/qemu setups. It is the combined work of 2 active gentoo devs Diego Petteno who created the main gentoo tinderbox, and Brian Harring. And does not work poorly and in my opinion works much better, easier than libvirt, which I never did get working before getting a copy of Brian's init script. -- Brian Dolbec dol...@gentoo.org signature.asc Description: This is a digitally signed message part
