Re: [gentoo-dev] Re: [gentoo-dev-announce] Changes in python_mod_optimize(), python_mod_cleanup() and python_mod_compile()
On 05/26/2010 08:28 AM, Alec Warner wrote: > On Tue, May 25, 2010 at 8:14 PM, Nirbheek Chauhan wrote: >> On Wed, May 26, 2010 at 2:19 AM, Arfrever Frehtes Taifersar Arahesis >> wrote: >>> 2010-05-25 21:11:44 Petteri Räty napisał(a): 1. Messages to gentoo-dev-announce should also be posted to an on topic mailing lists >>> >>> I don't like crossposting. >>> >> >> How do you expect people to have a conversation about a topic on a >> read-only mailing list? > > Set reply-to? :) > It would still make archives.gentoo.org suboptimal. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] bug wrangler queue is large...
Mike Frysinger writes: > the bug reporter can open their own bugs. gentoo developers can open any > bug. > that's about it. Which can be a pain for other users who suffered the same bug (and are probably on the CC list), the maintainer says to re-open if the problem is not fixed, the user finds the problem is still there but the bug reporter does not re-open the bug. All you can do is add a comment and hope that a developer sees it and re-opens the bug.
Re: [gentoo-dev] Re: [gentoo-dev-announce] Changes in python_mod_optimize(), python_mod_cleanup() and python_mod_compile()
On Tue, May 25, 2010 at 8:14 PM, Nirbheek Chauhan wrote: > On Wed, May 26, 2010 at 2:19 AM, Arfrever Frehtes Taifersar Arahesis > wrote: >> 2010-05-25 21:11:44 Petteri Räty napisał(a): >>> 1. Messages to gentoo-dev-announce should also be posted to an on topic >>> mailing lists >> >> I don't like crossposting. >> > > How do you expect people to have a conversation about a topic on a > read-only mailing list? Set reply-to? :) > > -- > ~Nirbheek Chauhan > > Gentoo GNOME+Mozilla Team > >
Re: [gentoo-dev] [Survey || RFC] autotools-utils.eclass
On Tuesday 25 May 2010 23:59:22 Maciej Mrozowski wrote: > On Tuesday 25 of May 2010 20:31:33 Mike Frysinger wrote: > > the library handling is incorrect. i dont think you can pass around > > --enable- shared all the time without having configure generate warnings > > about unknown options. > > > > default to --disable-static when static-libs > > doesnt exist is wrong -- that's the opposite of what you should be doing. > > ignoring the same issue as the share option i mentioned above. > > Right. It its safe to assume that when --disable-static/--enable-static is > available, then --disable-shared/--enable-shared is available as well? i think that's a fair assumption. the vast majority of shared/static enable/disable flags are coming in via libtool and not custom code. the few packages doing custom code can simply write their own econf call. > > the src_test func looks like its copying & pasting stuff from the PM. > > this really should be kept in the PM without duplicating it everywhere. > > Unfortunately src_test needs to be called in build dir (which is unknown to > PM). > Calling default_src_test is the best I could come up with. should be fine > But what's the most important - is there any interest in having such > eclass? I'm only going to add it when it's flexible enough to effectively > phase-out eutils/base/autotools/libtool individual uses for fully > autotools-controlled buildsystems. Otherwise there's no point in yet > another wrapper imho. personally, i probably wouldnt use this. but i dont even like base.eclass. and considering other people seem to like base.eclass, it's reasonable to think people would like this. the out-of-source building will trip up some packages for no reason other than $builddir != $srcdir, but those packages suck and should be fixed in general (unrelated to Gentoo). i imagine some maintainers would be annoyed by having to fix these. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] bug wrangler queue is large...
On Tuesday 25 May 2010 22:58:43 Jeroen Roovers wrote:
> On Tue, 25 May 2010 14:24:05 -0400 Mike Frysinger wrote:
> > On Tuesday 18 May 2010 02:02:01 Andreas K. Huettel wrote:
> > > could you please help the poor bug wranglers a bit?! The queue has
> > > reached 170 unassigned bugs...
> >
> > people dont seem to realize that bug-wranglers isnt just for
> > re-assigning to the proper maintainer. they are supposed to be doing
> > basic triage, user feedback, as well as cleaning up the bug. i
> > shouldnt be seeing bugs assigned to maintainers that have
> > "${PN}-1.ebuild" as their subject, nor bugs that lack basic things
> > like `emerge --info` or build logs.
>
> Without looking at the rest of this whole thread, that's lucky lucky
> wishful thinking. It doesn't match reality. Hope you're OK with that.
reality matches what i said. bug wranglers *are supposed to be*. if reality
matched what i wanted, then i wouldnt have written an e-mail of "supposed to
be" and "shouldnt be" statements.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [Survey || RFC] autotools-utils.eclass
Bummer...
Forgot to attach file in question.
--
regards
MM
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: autotools-utils.eclass
# @MAINTAINER:
# reave...@gentoo.org
# @DESCRIPTION:
# autotools.eclass and base.eclass wrapper providing all inherited features
along with:
# - myeconfargs - econf arguments as Bash array
# - out of source build (enabled by default) with overridable build dir location
# - static archives handling (static-libs in IUSE)
# - libtool archives removal (depending on static-libs USE flag)
# - enable/disable debug handling (debug in IUSE)
# Keep variable names synced with cmake-utils and the other way around!
case ${EAPI:-0} in
2|3|4) ;;
*) DEPEND="EAPI-TOO-OLD" ;;
esac
inherit autotools base
EXPORT_FUNCTIONS src_prepare src_configure src_compile src_install src_test
# Determine using IN or OUT source build
_check_build_dir() {
# @ECLASS-VARIABLE: ECONF_SOURCE
# @DESCRIPTION:
# Sets the directory where we are working with autotools.
# By default it uses ${S}.
: ${ECONF_SOURCE:=${S}}
# @ECLASS-VARIABLE: AUTOTOOLS_IN_SOURCE_BUILD
# @DESCRIPTION:
# Set to enable in-source build.
if [[ -n ${AUTOTOOLS_IN_SOURCE_BUILD} ]]; then
# @ECLASS-VARIABLE: AUTOTOOLS_BUILD_DIR
# @DESCRIPTION:
# Specify the build directory where all autotools generated
# files should be located.
# For installing binary doins "${AUTOTOOLS_BUILD_DIR}/somefile"
AUTOTOOLS_BUILD_DIR="${ECONF_SOURCE}"
else
: ${AUTOTOOLS_BUILD_DIR:=${WORKDIR}/${P}_build}
fi
echo ">>> Working in BUILD_DIR: \"$AUTOTOOLS_BUILD_DIR\""
}
# @FUNCTION: autotools-utils_src_prepare
# @DESCRIPTION:
# The src_prepare function, which is exported EAPI is greater or equal to 2.
autotools-utils_src_prepare() {
debug-print-function $FUNCNAME "$@"
# TODO Maybe some smart patching and automatic eautoreconf call?
base_src_prepare
}
# @FUNCTION: autotools-utils_src_configure
# @DESCRIPTION:
# The src_configure function, which is exported when EAPI is greater or equal
# to 2. Runs basic econf. Here the PATCHES array is evaluated.
autotools-utils_src_configure() {
debug-print-function $FUNCNAME "$@"
# @ECLASS-VARIABLE: myeconfargs
# @DESCRIPTION:
# econf arguments as Bash array
local econfargs=(
${myeconfar...@]}
)
# Handle debug found in IUSE
if has debug ${IUSE//+}; then
econfargs+=($(use_enable debug))
fi
# Handle static-libs found in IUSE, disable them by default
if has static-libs ${IUSE//+}; then
econfargs+=(
--enable-shared
$(use_enable static-libs static)
)
fi
_check_build_dir
mkdir -p "${AUTOTOOLS_BUILD_DIR}" || die "mkdir
'${AUTOTOOLS_BUILD_DIR}' failed"
pushd "${AUTOTOOLS_BUILD_DIR}" > /dev/null
base_src_configure "${econfar...@]}"
popd > /dev/null
}
# @FUNCTION: autotools-utils_src_compile
# @DESCRIPTION:
# The autotools src_compile function, calls src_configure with EAPI older
# than 2.
autotools-utils_src_compile() {
debug-print-function $FUNCNAME "$@"
_check_build_dir
pushd "${AUTOTOOLS_BUILD_DIR}" > /dev/null
base_src_compile "$@"
popd > /dev/null
}
# @FUNCTION: autotools-utils_src_install
# @DESCRIPTION:
# The autotools src_install function. Runs make install and removes libtool
files.
autotools-utils_src_install() {
debug-print-function $FUNCNAME "$@"
_check_build_dir
pushd "${AUTOTOOLS_BUILD_DIR}" > /dev/null
base_src_install
popd > /dev/null
# Remove libtool archives
if has static-libs ${IUSE//+} && ! use static-libs; then
find "${D}" -type f -name '*.la' -exec rm -f {} + \
|| die 'libtool archive removal failed'
fi
}
# @FUNCTION: autotools-utils_src_test
# @DESCRIPTION:
# The autotools src_test function. Runs emake check in source directory.
autotools-utils_src_test() {
debug-print-function ${FUNCNAME} "$@"
_check_build_dir
pushd "${AUTOTOOLS_BUILD_DIR}" > /dev/null
default_src_test
popd > /dev/null
}
Re: [gentoo-dev] [Survey || RFC] autotools-utils.eclass
On Tuesday 25 of May 2010 20:31:33 Mike Frysinger wrote: > internal functions should not be documented with the eclass doc comments > (_check_build_dir) Fixed. > reusing a PM variable (ECONF_SOURCE) seems a little iffy I know, initial idea was to use AUTOTOOLS_USE_DIR (analogy to CMAKE_USE_DIR), but then I discovered that I'd need to set ECONF_SOURCE anyway. So to avoid duplicating variables, I opted for ECONF_SOURCE reuse. If it's supposed to have internal meaning and is not part of public API, then I agree should not be used. I see it's explicitly mentioned in PMS though. Waiting for further comments on that matter. > the library handling is incorrect. i dont think you can pass around > --enable- shared all the time without having configure generate warnings > about unknown options. > default to --disable-static when static-libs > doesnt exist is wrong -- that's the opposite of what you should be doing. > ignoring the same issue as the share option i mentioned above. Right. It its safe to assume that when --disable-static/--enable-static is available, then --disable-shared/--enable-shared is available as well? > pushd/popd should have stdout sent to /dev/null, not stderr too Fixed. > the src_install func has the static-libs checks in the incorrect order Fixed. > the src_test func looks like its copying & pasting stuff from the PM. this > really should be kept in the PM without duplicating it everywhere. Unfortunately src_test needs to be called in build dir (which is unknown to PM). Calling default_src_test is the best I could come up with. But what's the most important - is there any interest in having such eclass? I'm only going to add it when it's flexible enough to effectively phase-out eutils/base/autotools/libtool individual uses for fully autotools-controlled buildsystems. Otherwise there's no point in yet another wrapper imho. I was also thinking of integrating parts of src_prepare from virtuoso.eclass into autotools-utils.eclass - it provides basic support for package splitting of well formed (TM) and clean autotools build systems. (example packages are virtuoso-odbc and virtuoso-server). Thanks -- regards MM
Re: [gentoo-dev] bug wrangler queue is large...
On Wed, 26 May 2010 05:02:10 +0200 Jeroen Roovers wrote: > http://www.gentoo.org/proj/en/qa/bug-wranglers/index.xml > > If you find that you can't do that, then we should be sorry for the > maintainers. Bug wrangling is the most unthankful job you can > voluntarily perform, so there. To follow up on that, we could add some language to the point that if it takes more than X days (say a week) then assignment to maintainers proper should go through. This could be especially important when bugs do seem relevant but should be looked at by someone (or a freakin' whole "herd") with somewhat more intimate knowledge of the package in question. Regards, jer
Re: [gentoo-dev] Re: [gentoo-dev-announce] Changes in python_mod_optimize(), python_mod_cleanup() and python_mod_compile()
On Wed, May 26, 2010 at 2:19 AM, Arfrever Frehtes Taifersar Arahesis wrote: > 2010-05-25 21:11:44 Petteri Räty napisał(a): >> 1. Messages to gentoo-dev-announce should also be posted to an on topic >> mailing lists > > I don't like crossposting. > How do you expect people to have a conversation about a topic on a read-only mailing list? -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] bug wrangler queue is large...
On Tue, 25 May 2010 23:40:44 +0200 Harald van Dijk wrote: > Yes, people like myself who don't normally wrangle bugs but try to > help out occasionally. I'm not really interested in receiving all bug > wrangler e-mails. Nobody should be required to read all that crap. :) jer
Re: [gentoo-dev] bug wrangler queue is large...
On Tue, 25 May 2010 22:08:55 +0200 Harald van Dijk wrote: > On Tue, May 25, 2010 at 03:33:33PM -0400, Mike Frysinger wrote: > > On Tuesday 25 May 2010 14:46:01 Matti Bickel wrote: > > > I wrangle bugs when there's a need and I'd > > > like to hear what maintainers want to see on a bug assigned to > > > them. If info is missing I usually ask for it and assign the bug > > > anyway. If that's not wanted, let me know. > > > > i dont feel like this should go to the maintainer yet. if a report > > is missing something that the maintainer needs, it isnt ready for > > them to look at. so wranglers ask for it, leave it assigned to > > bug-wranglers, and close as NEEDINFO. when (if) things become > > available, it can then be re-opened and moved to the maintainer. > > No, don't close as NEEDINFO, mark as ASSIGNED. NEEDINFO bugs cannot be > reopened by other users, even if they provide the requested > information. NEEDINFO bugs are also easily forgotten about when the > reporter forgets to reopen the bug him/herself. Plus, it's in the > docs anyway. If you have to CLOSE a bug because it's blatantly lacking the proper info, language, spelling etc, then CC yourself. It's the least you can do to make sure there's some kind of follow-up. Regards, jer
Re: [gentoo-dev] bug wrangler queue is large...
On Tue, 25 May 2010 20:46:01 +0200 Matti Bickel wrote: > On 05/25/2010 08:24 PM, Mike Frysinger wrote: > > they are supposed to be doing basic triage, user feedback > > Can you be more specific? I wrangle bugs when there's a need and I'd > like to hear what maintainers want to see on a bug assigned to them. > If info is missing I usually ask for it and assign the bug anyway. If > that's not wanted, let me know. > http://www.gentoo.org/proj/en/qa/bug-wranglers/index.xml If you find that you can't do that, then we should be sorry for the maintainers. Bug wrangling is the most unthankful job you can voluntarily perform, so there. Regards an happy wrangling, jer
Re: [gentoo-dev] bug wrangler queue is large...
On Tue, 25 May 2010 14:24:05 -0400
Mike Frysinger wrote:
> On Tuesday 18 May 2010 02:02:01 Andreas K. Huettel wrote:
> > could you please help the poor bug wranglers a bit?! The queue has
> > reached 170 unassigned bugs...
>
> people dont seem to realize that bug-wranglers isnt just for
> re-assigning to the proper maintainer. they are supposed to be doing
> basic triage, user feedback, as well as cleaning up the bug. i
> shouldnt be seeing bugs assigned to maintainers that have
> "${PN}-1.ebuild" as their subject, nor bugs that lack basic things
> like `emerge --info` or build logs. -mike
Without looking at the rest of this whole thread, that's lucky lucky
wishful thinking. It doesn't match reality. Hope you're OK with that.
Regards,
jer
Re: [gentoo-dev] bug wrangler queue is large...
On Tuesday 25 May 2010 17:06:39 Matti Bickel wrote: > On 05/25/2010 10:08 PM, Harald van Dijk wrote: > > NEEDINFO bugs cannot be reopened by other users, even if they provide > > the requested information. > > I utterly fail at finding documentation on that. I've recently hit a > problem where a user couldn't reopen a RESO FIXED bug, too. Are bugzi > permissions documented somewhere? the bug reporter can open their own bugs. gentoo developers can open any bug. that's about it. (there are other rules minor, but they arent really relevant) -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] bug wrangler queue is large...
On Tue, May 25, 2010 at 04:25:20PM -0400, Mike Frysinger wrote: > and people on the wrangler alias see that traffic, so the state doesnt > matter. > but i guess you're trying to cater to people who only scan the assigned list > rather than watching the e-mails sent to it. Yes, people like myself who don't normally wrangle bugs but try to help out occasionally. I'm not really interested in receiving all bug wrangler e-mails.
[gentoo-dev] Re: [Survey || RFC] autotools-utils.eclass
On Tuesday 25 of May 2010 13:02:55 Maciej Mrozowski wrote: > Also a patch for base.eclass to make it's econf accept arguments + some > random function documentation fix. Commited mentioned base.eclass patch + added quoting of positional parameter expansion. http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo- x86/eclass/base.eclass?r1=1.50&r2=1.52 -- regards MM
Re: [gentoo-dev] bug wrangler queue is large...
On 05/25/2010 10:08 PM, Harald van Dijk wrote: > NEEDINFO bugs cannot be reopened by other users, even if they provide > the requested information. I utterly fail at finding documentation on that. I've recently hit a problem where a user couldn't reopen a RESO FIXED bug, too. Are bugzi permissions documented somewhere? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] autotools.eclass eautomake update
On Tuesday 25 May 2010 16:38:16 Petteri Räty wrote: > On 05/25/2010 11:12 PM, Mike Frysinger wrote: > > On Tuesday 25 May 2010 16:02:04 Petteri Räty wrote: > >> Even if people don't have useful feedback sending the diff enables them > >> to prepare for the upcoming changes and provide support to users if > >> something goes wrong. > > > > which is irrelevant here because i did notify people of the change > > My point was that if you are going to send an email to gentoo-dev any > way, why not do it earlier with the diff? because all of the e-mail stuff occurred to me after the fact -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-dev-announce] Changes in python_mod_optimize(), python_mod_cleanup() and python_mod_compile()
2010-05-25 21:11:44 Petteri Räty napisał(a): > On 05/25/2010 09:35 PM, Arfrever Frehtes Taifersar Arahesis wrote: > > - Not passing of paths to python_mod_optimize() and python_mod_cleanup() > > has been > > deprecated and will be disallowed on 2010-09-01. You should pass paths to > > Python > > modules to these functions. > > > > - python_mod_compile() has been deprecated and will be banned on 2010-09-01. > > You should use python_mod_optimize() instead of python_mod_compile(). > > > > 1. Messages to gentoo-dev-announce should also be posted to an on topic > mailing lists I don't like crossposting. > 2. What does disallowed and banned mean in this case? Plenty of ebuilds > currently pass paths to python_mod_optimize. Ebuilds, which pass paths to python_mod_optimize() / python_mod_cleanup(), don't need any changes. Ebuilds, which don't pass paths to python_mod_optimize() or python_mod_cleanup(), should now pass paths to these functions. Only small minority of ebuilds don't pass paths to these functions. python_mod_optimize() without paths hasn't been doing anything for almost 2 years. python_mod_cleanup() without paths allows for silently incorrect behavior. Not passing of paths to python_mod_cleanup() is incorrect in many ebuilds. > If you break the stable tree, you should have the wrath of more people than > me. > It can be done at the dates you say if the tree is in order by then. I'm not breaking anything. Deprecation warnings won't be changed into calls to die() until all ebuilds in gentoo-x86 are fixed. It's possible to deprecate and ban functions or their parts as it was discussed in "Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI <=2" thread [1]. [1] http://archives.gentoo.org/gentoo-dev/msg_7ad37800b8fa3041662068f70083cb56.xml -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] autotools.eclass eautomake update
On 05/25/2010 11:12 PM, Mike Frysinger wrote: > On Tuesday 25 May 2010 16:02:04 Petteri Räty wrote: >> Even if people don't have useful feedback sending the diff enables them >> to prepare for the upcoming changes and provide support to users if >> something goes wrong. > > which is irrelevant here because i did notify people of the change > -mike My point was that if you are going to send an email to gentoo-dev any way, why not do it earlier with the diff? The only trouble to you is attaching the diff and as said it can have benefits. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] bug wrangler queue is large...
On Tuesday 25 May 2010 16:08:55 Harald van Dijk wrote: > On Tue, May 25, 2010 at 03:33:33PM -0400, Mike Frysinger wrote: > > On Tuesday 25 May 2010 14:46:01 Matti Bickel wrote: > > > I wrangle bugs when there's a need and I'd > > > like to hear what maintainers want to see on a bug assigned to them. > > > If info is missing I usually ask for it and assign the bug anyway. If > > > that's not wanted, let me know. > > > > i dont feel like this should go to the maintainer yet. if a report is > > missing something that the maintainer needs, it isnt ready for them to > > look at. so wranglers ask for it, leave it assigned to bug-wranglers, > > and close as NEEDINFO. when (if) things become available, it can then > > be re-opened and moved to the maintainer. > > No, don't close as NEEDINFO, mark as ASSIGNED. NEEDINFO bugs cannot be > reopened by other users, even if they provide the requested information. > NEEDINFO bugs are also easily forgotten about when the reporter forgets > to reopen the bug him/herself. and people on the wrangler alias see that traffic, so the state doesnt matter. but i guess you're trying to cater to people who only scan the assigned list rather than watching the e-mails sent to it. > Plus, it's in the docs anyway. then i guess i'll point this out to those who wrangle these things to maintainers w/out following the docs. thanks. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] bug wrangler queue is large...
On 05/25/2010 10:08 PM, Harald van Dijk wrote: > http://www.gentoo.org/proj/en/qa/bug-wranglers/index.xml Cool, I clearly not up to date here, I've never thought this to be a project. Thanks for the link. Wrt mentioning metadata.xml for herd lookup in there: I've found willikins' meta -v (in a query, mind you) saves me a few keystrokes. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] autotools.eclass eautomake update
On Tuesday 25 May 2010 16:02:04 Petteri Räty wrote: > Even if people don't have useful feedback sending the diff enables them > to prepare for the upcoming changes and provide support to users if > something goes wrong. which is irrelevant here because i did notify people of the change -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] bug wrangler queue is large...
On Tue, May 25, 2010 at 03:33:33PM -0400, Mike Frysinger wrote: > On Tuesday 25 May 2010 14:46:01 Matti Bickel wrote: > > I wrangle bugs when there's a need and I'd > > like to hear what maintainers want to see on a bug assigned to them. > > If info is missing I usually ask for it and assign the bug anyway. If > > that's not wanted, let me know. > > i dont feel like this should go to the maintainer yet. if a report is > missing > something that the maintainer needs, it isnt ready for them to look at. so > wranglers ask for it, leave it assigned to bug-wranglers, and close as > NEEDINFO. when (if) things become available, it can then be re-opened and > moved to the maintainer. No, don't close as NEEDINFO, mark as ASSIGNED. NEEDINFO bugs cannot be reopened by other users, even if they provide the requested information. NEEDINFO bugs are also easily forgotten about when the reporter forgets to reopen the bug him/herself. Plus, it's in the docs anyway. "Do not assume that the reporter ought to know how to report bugs. An omitted `emerge --info' does not call for a public flogging, it simply calls for the missing `emerge --info'. Even experienced reporters make mistakes, so simply request the information, mark the bug as ASSIGNED and wait for the information you requested." http://www.gentoo.org/proj/en/qa/bug-wranglers/index.xml
Re: [gentoo-dev] bug wrangler queue is large...
On 05/25/2010 09:33 PM, Mike Frysinger wrote:
> i posted some specific examples already ...
Sure enough. Just wanted to know if there's more to it than build.log
and emerge --info. I'll try to extract something more than that next
time. Goes w/o saying that bug cleanup should be done prior
to assignments.
> so wranglers ask for it, leave it assigned to bug-wranglers, and
> close as NEEDINFO. when (if) things become available, it can then be
> re-opened and moved to the maintainer. -mike
Good enough for me. The intention behind the immediate assignments was
the hope that maintainers could figure out the error from the already
provided info ("does not work" won't get assigned), netting quicker
reaction times.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] autotools.eclass eautomake update
On 05/25/2010 01:17 AM, Mike Frysinger wrote: > On Mon, May 24, 2010 at 5:53 PM, Petteri Räty wrote: >> On 24.5.2010 23.51, Mike Frysinger wrote: >>> On Mon, May 24, 2010 at 4:44 AM, Petteri Räty wrote: On 24.5.2010 1.54, Mike Frysinger wrote: > ive updated eautomake to run automake in a few more edge cases. hopefully > this doesnt break anything else (seems to not on my system), but who > knows. > > if you see random eautoreconf/eautomake failure, try backing out the > autotools.eclass change first. I think any autotools.eclass behavior changes would benefit from being sent to gentoo-dev for review first. >>> >>> if i felt most people had an understanding of how autotools worked let >>> alone how autotools.eclass, then perhaps i would >> >> And what do you loose by sending them here? The devmanual text strictly >> doesn't enforce it but strongly encourages: "Before updating eutils or a >> similar widely used eclass, it is best to email the gentoo-dev list." > > so prove me wrong and post some useful feedback on the change. i'm > simply being realistic. > sources.gentoo.org/eclass/autotools.eclass?r1=1.97&r2=1.98 > -mike > Even if people don't have useful feedback sending the diff enables them to prepare for the upcoming changes and provide support to users if something goes wrong. Regards, PEtteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last-rites sci-libs/rcsb-data sci-chemistry/maxit sci-chemistry/validation
On 22/05/10 10:40, justin wrote: > # Justin Lecher (16 May 2010) > # bug 296755 296651 252649 > # breaks with newer glibc, gcc and deps > # file collision with other packages > # no one cares and fixes that > # nearly fully replaced by other packages > # Last rited today > sci-libs/rcsb-data > sci-chemistry/validation > sci-chemistry/maxit > =pdb-extract/pdb-extract-1.700 > I will delay this a couple of month, as the dep tree gets horribly broken. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] autotools.eclass eautomake update
On Tuesday 25 May 2010 15:22:14 Rémi Cardona wrote: > Le 25/05/2010 09:23, Mike Frysinger a écrit : > >> Even if you think no one will ever comment on your patches, I've seen > >> enough projects where posting patches and doing reviews generated > >> interest and got people to contribute. > > > > i'm just asking for proof that it's useful here > > And I'm asking you to try it regardless of proof. Consider this a social > experiment. i didnt say i wouldnt, just that i was being realistic -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] bug wrangler queue is large...
On Tuesday 25 May 2010 14:46:01 Matti Bickel wrote: > On 05/25/2010 08:24 PM, Mike Frysinger wrote: > > they are supposed to be doing basic triage, user feedback > > Can you be more specific? i posted some specific examples already ... a little double checking of reports and suggestion of basic debugging steps (strace/whatever) would be nice, but i can let that slide since this is a bit more package specific. > I wrangle bugs when there's a need and I'd > like to hear what maintainers want to see on a bug assigned to them. > If info is missing I usually ask for it and assign the bug anyway. If > that's not wanted, let me know. i dont feel like this should go to the maintainer yet. if a report is missing something that the maintainer needs, it isnt ready for them to look at. so wranglers ask for it, leave it assigned to bug-wranglers, and close as NEEDINFO. when (if) things become available, it can then be re-opened and moved to the maintainer. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] bug wrangler queue is large...
On 05/25/2010 02:24 PM, Mike Frysinger wrote:
On Tuesday 18 May 2010 02:02:01 Andreas K. Huettel wrote:
could you please help the poor bug wranglers a bit?! The queue has reached
170 unassigned bugs...
people dont seem to realize that bug-wranglers isnt just for re-assigning to
the proper maintainer. they are supposed to be doing basic triage, user
feedback, as well as cleaning up the bug. i shouldnt be seeing bugs assigned
to maintainers that have "${PN}-1.ebuild" as their subject, nor bugs that lack
basic things like `emerge --info` or build logs.
As long as the status quo works I don't think we need to change it.
However if we are running into issues with keeping up it might make
sense to just have wranglers do assignments to maintainers and let the
maintainers deal with the rest.
The reason is that the maintainer might be able to spot dups much more
readily, or spot obvious solutions to bugs, where a wrangler might be
hunting around.
By all means wranglers should do what they can when they can, but keep
in mind that if you yell at a wrangler any time they "do it wrong" a
natural response of devs will be to not bother with bug wrangling or
just looking for their own bugs in the list.
I'm not necessarily proposing any changes here, but in general we need
to be careful about barriers to entry in projects that are undermanned.
Rich
Re: [gentoo-dev] autotools.eclass eautomake update
Le 25/05/2010 09:23, Mike Frysinger a écrit : >> Even if you think no one will ever comment on your patches, I've seen >> enough projects where posting patches and doing reviews generated >> interest and got people to contribute. > > i'm just asking for proof that it's useful here And I'm asking you to try it regardless of proof. Consider this a social experiment. > no, because that isnt how autoreconf works today. current behavior mimics > current autotools. Makes sense, thanks for the explanation. Cheers, Rémi
[gentoo-dev] Re: [gentoo-dev-announce] Changes in python_mod_optimize(), python_mod_cleanup() and python_mod_compile()
On 05/25/2010 09:35 PM, Arfrever Frehtes Taifersar Arahesis wrote: > - Not passing of paths to python_mod_optimize() and python_mod_cleanup() has > been > deprecated and will be disallowed on 2010-09-01. You should pass paths to > Python > modules to these functions. > > - python_mod_compile() has been deprecated and will be banned on 2010-09-01. > You should use python_mod_optimize() instead of python_mod_compile(). > 1. Messages to gentoo-dev-announce should also be posted to an on topic mailing lists 2. What does disallowed and banned mean in this case? Plenty of ebuilds currently pass paths to python_mod_optimize. If you break the stable tree, you should have the wrath of more people than me. It can be done at the dates you say if the tree is in order by then. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] bug wrangler queue is large...
On 05/25/2010 08:24 PM, Mike Frysinger wrote: > they are supposed to be doing basic triage, user feedback Can you be more specific? I wrangle bugs when there's a need and I'd like to hear what maintainers want to see on a bug assigned to them. If info is missing I usually ask for it and assign the bug anyway. If that's not wanted, let me know. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [Survey || RFC] autotools-utils.eclass
internal functions should not be documented with the eclass doc comments (_check_build_dir) reusing a PM variable (ECONF_SOURCE) seems a little iffy the library handling is incorrect. i dont think you can pass around --enable- shared all the time without having configure generate warnings about unknown options. default to --disable-static when static-libs doesnt exist is wrong -- that's the opposite of what you should be doing. ignoring the same issue as the share option i mentioned above. pushd/popd should have stdout sent to /dev/null, not stderr too the src_install func has the static-libs checks in the incorrect order the src_test func looks like its copying & pasting stuff from the PM. this really should be kept in the PM without duplicating it everywhere. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] bug wrangler queue is large...
On Tuesday 18 May 2010 02:02:01 Andreas K. Huettel wrote:
> could you please help the poor bug wranglers a bit?! The queue has reached
> 170 unassigned bugs...
people dont seem to realize that bug-wranglers isnt just for re-assigning to
the proper maintainer. they are supposed to be doing basic triage, user
feedback, as well as cleaning up the bug. i shouldnt be seeing bugs assigned
to maintainers that have "${PN}-1.ebuild" as their subject, nor bugs that lack
basic things like `emerge --info` or build logs.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: autotools.eclass eautomake update
El mar, 25-05-2010 a las 16:45 +0400, Peter Volkov escribió:
> В Втр, 25/05/2010 в 12:12 +, Duncan пишет:
> > Peter Volkov posted on Tue, 25 May 2010 11:46:12 +0400 as excerpted:
> > >> sources.gentoo.org/eclass/autotools.eclass?r1=1.97&r2=1.98
> > > Why "" is required at the end of file list?
>
> > for makefile_name in {GNUmakefile,{M,m}akefile}.{am,in} "" ; do
> > [[ -f ${makefile_name} ]] && break
> > done
>
> > the purpose of the "" case, if none of the tested filename
> > variants exists, it leaves the variable empty.
>
> Thank you Duncan. Now I see :)
>
From my point of view, seems quite obvious that it's interesting to post
that eclass changes as, even if it's fully ok, it helps other devs (like
me) to learn more :-)
Best regards
signature.asc
Description: Esta parte del mensaje está firmada digitalmente
Re: [gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs -- humpback, genstef, wrobel
Stanislav Ochotnicky schrieb: > On 05/25/2010 01:39 PM, Chí-Thanh Christopher Nguyễn wrote: > >> Torsten Veller schrieb: >> >>> media-video/linux-uvc >>> >>> >> I guess this package can be treecleaned, since current kernels contain >> the USB video class driver, and IIRC it no longer builds. >> > I believe these are (at least partially) userspace tools for linux-avc, > not sure about the kernel part... > I thought the userspace tools were in the media-video/luvcview package. But I could be mistaken. Regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: autotools.eclass eautomake update
В Втр, 25/05/2010 в 12:12 +, Duncan пишет:
> Peter Volkov posted on Tue, 25 May 2010 11:46:12 +0400 as excerpted:
> >> sources.gentoo.org/eclass/autotools.eclass?r1=1.97&r2=1.98
> > Why "" is required at the end of file list?
> for makefile_name in {GNUmakefile,{M,m}akefile}.{am,in} "" ; do
> [[ -f ${makefile_name} ]] && break
> done
> the purpose of the "" case, if none of the tested filename
> variants exists, it leaves the variable empty.
Thank you Duncan. Now I see :)
--
Peter.
Re: [gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs -- humpback, genstef, wrobel
On 05/25/2010 01:39 PM, Chí-Thanh Christopher Nguyễn wrote: > Torsten Veller schrieb: >> media-video/linux-uvc >> > > I guess this package can be treecleaned, since current kernels contain > the USB video class driver, and IIRC it no longer builds. I believe these are (at least partially) userspace tools for linux-avc, not sure about the kernel part... -- Stanislav Ochotnicky PGP: 71A1677C jabber: stanis...@ochotnicky.com signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: autotools.eclass eautomake update
Peter Volkov posted on Tue, 25 May 2010 11:46:12 +0400 as excerpted:
> В Пнд, 24/05/2010 в 18:17 -0400, Mike Frysinger пишет:
>> sources.gentoo.org/eclass/autotools.eclass?r1=1.97&r2=1.98
>
> for makefile_name in {GNUmakefile,{M,m}akefile}.{am,in} "" ; do
>
> Why "" is required at the end of file list?
Interesting coding trick! =:^) Here's that bit of code in full (watch the
wrap):
for makefile_name in {GNUmakefile,{M,m}akefile}.{am,in} "" ; do
[[ -f ${makefile_name} ]] && break
done
[[ -z ${makefile_name} ]] && return 0
The for loop itself doesn't really do anything, except short-circuit
itself with a break if the named file exists. What is its purpose, then?
The purpose of the loop is to leave the name of the actual existing
makefile in the variable makefile_name...
**OR**, the purpose of the "" case, if none of the tested filename
variants exists, it leaves the variable empty.
The next line then tests for the last case, the empty variable, and short-
circuits the eautomake function itself in that condition, returning 0/no-
error/true.
Without the "" case, the for loop would leave the last tested filename in
the variable whether it existed or not, and the test for the empty
variable wouldn't work.
The perhaps more common alternative would be to test the exit status of
the for loop, which returns the exist status of the last command, in this
case either break (which would return zero/no-error/true), or the [[ -f ]]
test itself (which would return 1/false/error if break didn't run). That
would result in something like this (untested) code:
for makefile_name in {GNUmakefile,{M,m}akefile}.{am,in} ; do
[[ -f ${makefile_name} ]] && break
done && return
Assuming no error in my logic (a bit of an assumption since my code isn't
tested and I expect his code was), I'm not sure why that code wasn't used,
unless it was deemed less clear (perhaps the && return is too easy to
miss, tho a separate [[ $? = 0 ]] && return would fix that), or was simple
choice of coding style.
While we're at it, in "&& return 0", the "0" is ALWAYS superfluous, as
"return" returns the exit code of the last command by default, which MUST
be zero or the "&&" logic would have failed, so the "&& return"
combination will ALWAYS return 0. But that too may be coding style, as
the "return 0" makes it explicit, a reasonable enough policy.
--
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] Re: [gentoo-dev-announce] Packages up for grabs -- humpback, genstef, wrobel
Torsten Veller schrieb: > media-video/linux-uvc > I guess this package can be treecleaned, since current kernels contain the USB video class driver, and IIRC it no longer builds. > x11-libs/agg > Unless science herd wants it, I can take this, as I already co-maintain www-plugins/gnash which is one of the principal users of agg. Regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] [Survey || RFC] autotools-utils.eclass
Is anyone interested in cmake-utils like autotools/base wrapper?
Features:
- base.eclass autopatcher (including user patches)
- myeconfargs - econf arguments as Bash array (usage like mycmakeargs in
cmake-utils)
- out of source build (enabled by default) with overridable build dir location
- static archives handling (enable/disable static based on static-libs in
IUSE)
- libtool archives removal (depending on static-libs USE flag)
- enable/disable debug handling (debug in IUSE)
- cmake-utils resemblance (DOCS, HTML_DOCS variables)
- ???
- Profit! ;)
Example usage in attached clucene-0.9.21b-r1.
Also a patch for base.eclass to make it's econf accept arguments + some random
function documentation fix.
--
regards
MM
Index: base.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/base.eclass,v
retrieving revision 1.50
diff -u -B -r1.50 base.eclass
--- base.eclass 12 Apr 2010 15:33:03 - 1.50
+++ base.eclass 25 May 2010 10:46:31 -
@@ -65,7 +65,7 @@
# @FUNCTION: base_src_prepare
# @DESCRIPTION:
# The base src_prepare function, which is exported
-# EAPI is greater or equal to 2.
+# EAPI is greater or equal to 2. Here the PATCHES array is evaluated.
base_src_prepare() {
debug-print-function $FUNCNAME "$@"
debug-print "$FUNCNAME: PATCHES=$PATCHES"
@@ -116,13 +116,12 @@
# @FUNCTION: base_src_configure
# @DESCRIPTION:
# The base src_configure function, which is exported when
-# EAPI is greater or equal to 2. Runs basic econf. Here the PATCHES array is
-# evaluated.
+# EAPI is greater or equal to 2. Runs basic econf.
base_src_configure() {
debug-print-function $FUNCNAME "$@"
# there is no pushd ${S} so we can override its place where to run
- [[ -x ${ECONF_SOURCE:-.}/configure ]] && econf
+ [[ -x ${ECONF_SOURCE:-.}/configure ]] && econf $@
}
# @FUNCTION: base_src_compile
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: autotools-utils.eclass
# @MAINTAINER:
# reave...@gentoo.org
# @DESCRIPTION:
# autotools.eclass and base.eclass wrapper providing following features:
# - autopatcher (including user patches)
# - myeconfargs - econf arguments as Bash array
# - out of source build (enabled by default) with overridable build dir location
# - static archives handling (static-libs in IUSE)
# - libtool archives removal (depending on static-libs USE flag)
# - enable/disable debug handling (debug in IUSE)
# - cmake-utils resemblance (DOCS, HTML_DOCS variables)
# Keep variable names synced with cmake-utils!
case ${EAPI:-0} in
2|3|4) ;;
*) DEPEND="EAPI-TOO-OLD" ;;
esac
inherit autotools base
EXPORT_FUNCTIONS src_prepare src_configure src_compile src_install src_test
# @ECLASS-VARIABLE: AUTOTOOLS_IN_SOURCE_BUILD
# @DESCRIPTION:
# Set to enable in-source build.
# @FUNCTION: _check_build_dir
# @DESCRIPTION:
# Determine using IN or OUT source build
_check_build_dir() {
# @ECLASS-VARIABLE: ECONF_SOURCE
# @DESCRIPTION:
# Sets the directory where we are working with autotools.
# By default it uses ${S}.
: ${ECONF_SOURCE:=${S}}
# @ECLASS-VARIABLE: AUTOTOOLS_BUILD_DIR
# @DESCRIPTION:
# Specify the build directory where all autotools generated
# files should be located.
# For installing binary doins "${AUTOTOOLS_BUILD_DIR}/somefile"
if [[ -n ${AUTOTOOLS_IN_SOURCE_BUILD} ]]; then
# we build in source dir
AUTOTOOLS_BUILD_DIR="${ECONF_SOURCE}"
else
: ${AUTOTOOLS_BUILD_DIR:=${WORKDIR}/${P}_build}
fi
echo ">>> Working in BUILD_DIR: \"$AUTOTOOLS_BUILD_DIR\""
}
# @FUNCTION: autotools-utils_src_prepare
# @DESCRIPTION:
# The src_prepare function, which is exported EAPI is greater or equal to 2.
autotools-utils_src_prepare() {
debug-print-function $FUNCNAME "$@"
# TODO Maybe some smart patching and automatic eautoreconf call?
base_src_prepare
}
# @FUNCTION: autotools-utils_src_configure
# @DESCRIPTION:
# The src_configure function, which is exported when EAPI is greater or equal
# to 2. Runs basic econf. Here the PATCHES array is evaluated.
autotools-utils_src_configure() {
debug-print-function $FUNCNAME "$@"
# @ECLASS-VARIABLE: myeconfargs
# @DESCRIPTION:
# econf arguments as Bash array, enable shared libs by default
local econfargs=(
--enable-shared
${myeconfar...@]}
)
# Handle debug found in IUSE
if has debug ${IUSE//+}; then
econfargs+=($(use_enable debug))
fi
# Handle static-libs found in IUSE, disable them by default
if has static-libs ${IUSE//+}; then
econfargs+=($(use_enable static-libs static))
else
econfargs+=(--disable-static)
fi
_check_build_dir
mkdir -p
[gentoo-dev] Re: [gentoo-dev-announce] Packages up for grabs -- humpback, genstef, wrobel
On Tue, May 25, 2010 at 11:39:10AM +0200, Torsten Veller wrote: > Here's a bunch of packages up for grabs, due to maintainers retiring.. > > maintainer-needed > - > sys-apps/ivman grabbed this one ;) -- Alex Alexander :: wired Gentoo Developer www.linuxized.com pgpwhTJeyfRfC.pgp Description: PGP signature
Re: [gentoo-dev] autotools.eclass eautomake update
В Пнд, 24/05/2010 в 18:17 -0400, Mike Frysinger пишет:
> sources.gentoo.org/eclass/autotools.eclass?r1=1.97&r2=1.98
for makefile_name in {GNUmakefile,{M,m}akefile}.{am,in} "" ; do
Why "" is required at the end of file list?
--
Peter.
Re: [gentoo-dev] autotools.eclass eautomake update
On Tuesday 25 May 2010 02:54:27 Rémi Cardona wrote: > Le 25/05/2010 00:17, Mike Frysinger a écrit : > > so prove me wrong and post some useful feedback on the change. i'm > > simply being realistic. > > Even if you think no one will ever comment on your patches, I've seen > enough projects where posting patches and doing reviews generated > interest and got people to contribute. i'm just asking for proof that it's useful here > > sources.gentoo.org/eclass/autotools.eclass?r1=1.97&r2=1.98 > > Maybe you should grep for AC_INIT_AUTOMAKE too, as that's what lots of > folks used a while ago. no, because that isnt how autoreconf works today. current behavior mimics current autotools. -mike signature.asc Description: This is a digitally signed message part.
