Re: [gentoo-dev] bug wrangler queue is large...
On 05:30 Wed 26 May , Jeroen Roovers wrote: > 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. > Another idea crossed my mind when I was bug-wrangling the other day, that could help, until Robin's "automatic assignment computation of bugs"[1] gets implemented and becomes reality. What if we create a partial-bug-wranglers mail alias, write a cron job to calculate statistics from from the bug-wranglers queue and send mails to that alias according to various rules eg. to send mail when the queue passed a limit of bugs eg. 100 or 200 unassigned, or statistics about how many bugs that were reported before more than a week are still in the queue. This way, people like me, who are willing to do partial bug-wrangling, they just add themselves in the alias and get activated only when the queue is huge or there are many old bugs around. The mails could work well as a reminder and we avoid the huge bug-wranlgers mail traffic when we monitor them in bugzie. I don't have time now, to implement any of this, I don't know even if it's a good idea, but if you like it, I could try to write a working script in some weeks (thanks to Jeremy(darkside) for showing me the pybugz magic and Christian(idl0r) for the curl magic). [1] http://thread.gmane.org/gmane.linux.gentoo.devel/66279 -- Panagiotis Christopoulos ( pchrist ) ( Gentoo Lisp Project ) pgp54AaVjRZQK.pgp Description: PGP signature
[gentoo-dev] Links to compressed files (was: gentoo-x86 commit in app-misc/mmv: ChangeLog mmv-1.01b_p15.ebuild)
> src_install() {
> doman mmv.1 || die
> dosym mmv.1.gz /usr/share/man/man1/mcp.1.gz || die
> dosym mmv.1.gz /usr/share/man/man1/mln.1.gz || die
> dosym mmv.1.gz /usr/share/man/man1/mad.1.gz || die
How does this work with various package managers?
Portage works fine with different PORTAGE_COMPRESS settings.
I guess paludis creates uncompressed man-pages and has three broken links?
And pkgcore?
Is there a reliable/predictable way to create such links?
Re: [gentoo-dev] Links to compressed files
On 05/26/2010 10:47 AM, Torsten Veller wrote:
>> src_install() {
>
>> doman mmv.1 || die
>> dosym mmv.1.gz /usr/share/man/man1/mcp.1.gz || die
>> dosym mmv.1.gz /usr/share/man/man1/mln.1.gz || die
>> dosym mmv.1.gz /usr/share/man/man1/mad.1.gz || die
>
> How does this work with various package managers?
>
> Portage works fine with different PORTAGE_COMPRESS settings.
> I guess paludis creates uncompressed man-pages and has three broken links?
> And pkgcore?
>
> Is there a reliable/predictable way to create such links?
>
This is wrong (but works fine with Portage),
local suffix=$(ecompress --suffix)
dosym foo.1${suffix} /usr/share/man/man1/foo.1${suffix}
What you really want to do is:
ssuomi...@foo /usr/share/man/man1 $ bzcat snice.1.bz2
.so man1/skill.1
This simple one-liner & "fake" manpage will link snice(1) manpage to
skill(1) manpage.
Re: [gentoo-dev] Links to compressed files (was: gentoo-x86 commit in app-misc/mmv: ChangeLog mmv-1.01b_p15.ebuild)
> On Wed, 26 May 2010, Torsten Veller wrote: >> dosym mmv.1.gz /usr/share/man/man1/mcp.1.gz || die >> dosym mmv.1.gz /usr/share/man/man1/mln.1.gz || die >> dosym mmv.1.gz /usr/share/man/man1/mad.1.gz || die > Is there a reliable/predictable way to create such links? Don't use a symlink, but create a short file with a groff .so request. See for example the egrep.1 man page, that just contains the one line: .so man1/grep.1 Ulrich
Re: [gentoo-dev] Links to compressed files (was: gentoo-x86 commit in app-misc/mmv: ChangeLog mmv-1.01b_p15.ebuild)
On Wednesday 26 May 2010 04:01:28 Ulrich Mueller wrote: > > On Wed, 26 May 2010, Torsten Veller wrote: > >> dosym mmv.1.gz /usr/share/man/man1/mcp.1.gz || die > >> dosym mmv.1.gz /usr/share/man/man1/mln.1.gz || die > >> dosym mmv.1.gz /usr/share/man/man1/mad.1.gz || die > > > > Is there a reliable/predictable way to create such links? > > Don't use a symlink, but create a short file with a groff .so request. > See for example the egrep.1 man page, that just contains the one line: > >.so man1/grep.1 wonder if this would be a useful repoman check & recommendation. dare i grep the tree to find all the existing miscreants ... personally i prefer '.so grep.1' to avoid the redundancy ... -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: bug wrangler queue is large...
Graham Murray posted on Wed, 26 May 2010 06:36:35 +0100 as excerpted: > 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. That's what clone bug is for... or at least what /I/ use it for. If I'm not the bug OR/owner and I'm still seeing the bug, I can't open the existing one, but I can clone it, with an explanation why, about the best that can be done under the circumstances. It's then upto the wranglers whether they want to reopen the old one and make the new one a dup, or occasionally there's different minor details (maybe a patch didn't get applied or doesn't apply to a new version), and it can be argued to be a new bug, simply related to the old one. Either way, the wranglers or package maintainer get to decide. -- 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] Re: bug wrangler queue is large...
On 05/26/2010 11:01 AM, Duncan wrote: [Reopening on RESO FIXED bugs as non-reporter] > That's what clone bug is for... or at least what /I/ use it for. Resulting in extra work for wranglers. At least for the packages I maintain, I actually read my bugmail and will respond to comments even in RESO FIXED bugs. Plus, you're still screwed if users help out with the wrangling. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [Survey || RFC] autotools-utils.eclass
Mike Frysinger posted on Wed, 26 May 2010 00:31:21 -0400 as excerpted: > On Tuesday 25 May 2010 23:59:22 Maciej Mrozowski wrote: >> On Tuesday 25 of May 2010 20:31:33 Mike Frysinger wrote: >>> the src_test func looks like its copying & pasting stuff from the PM. >>> this really should be kept in the PM without duplicating it >>> everywhere. >> >> Unfortunately src_test needs to be called in build dir (which is >> unknown to PM). >> Calling default_src_test is the best I could come up with. > > should be fine What about a one-liner explaining why it's here, so the next guy to look at it won't be having MF's reaction all over again? -- 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: bug wrangler queue is large...
Jeroen Roovers posted on Wed, 26 May 2010 05:08:44 +0200 as excerpted: > 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. :) I've often wished there was a way to flag a bug as "I'm not thru messing with it yet, don't mail anyone yet." That's especially true when I know I'm going to be attaching 2-3 addition files, emerge --info, build log, maybe sth else like a config file or even a patch, where I know the wranglers are going to get all those extra mails. Or, if there was a way to attach files as part of the initial filing, but if there is, I've not found it. Alternatively, for normal bugs at least, maybe attaching emerge --info can be made a part of the process, with the post-submit note saying the bug won't be reported until that second step. (Then for bugs that clearly don't need it, where the bug's clearly in an initscript or something, have a checkbox on that second step saying "emerge --info shouldn't be needed for this.") That would both encourage emerge --info submission AND prevent one layer of bug spam at the same time! =:^) -- 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] Re: [Survey || RFC] autotools-utils.eclass
On Wednesday 26 of May 2010 11:12:10 Duncan wrote:
> Mike Frysinger posted on Wed, 26 May 2010 00:31:21 -0400 as excerpted:
> > On Tuesday 25 May 2010 23:59:22 Maciej Mrozowski wrote:
> >> On Tuesday 25 of May 2010 20:31:33 Mike Frysinger wrote:
> >>> the src_test func looks like its copying & pasting stuff from the PM.
> >>> this really should be kept in the PM without duplicating it
> >>> everywhere.
> >>
> >> Unfortunately src_test needs to be called in build dir (which is
> >> unknown to PM).
> >> Calling default_src_test is the best I could come up with.
> >
> > should be fine
>
> What about a one-liner explaining why it's here, so the next guy to
> look at it won't be having MF's reaction all over again?
Again?
I've updated documentation, added example usage and option to keep libtool
files (ltdl.so supposedly needs those as I was told, no idea what for).
--
regards
MM
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: autotools-utils.eclass
# @MAINTAINER:
# Maciej Mrozowski
# @BLURB: common ebuild functions for autotools-based packages
# @DESCRIPTION:
# autotools-utils.eclass is autotools.eclass(5) and base.eclass(5) wrapper
# providing all inherited features along with econf arguments as Bash array,
# out of source build with overridable build dir location, static archives
# handling, libtool archives removal, enable/disable debug handling.
#
# @EXAMPLE:
# Typical ebuild using autotools-utils.eclass:
#
# @CODE
# EAPI="2"
#
# inherit autotools-utils
#
# DESCRIPTION="Foo bar application"
# HOMEPAGE="http://foo.org/";
# SRC_URI="mirror://sourceforge/foo/${P}.tar.bz2"
#
# LICENSE="LGPL-2.1"
# KEYWORDS=""
# SLOT="0"
# IUSE="debug examples qt4 static-libs tiff"
#
# DEPEND="
# media-libs/libpng:0
# qt4? (
# x11-libs/qt-core:4
# x11-libs/qt-gui:4
# )
# tiff? ( media-libs/tiff:0 )
# "
# RDEPEND="${DEPEND}
# !media-gfx/bar
# "
#
# # bug 123456
# AUTOTOOLS_IN_SOURCE_BUILD=1
#
# DOCS=(AUTHORS ChangeLog README "Read me.txt" TODO)
#
# PATCHES=(
# "${FILESDIR}/${P}-gcc44.patch" # bug 123458
# "${FILESDIR}/${P}-as-needed.patch"
# "${FILESDIR}/${P}-unbundle_libpng.patch"
# )
#
# src_configure() {
# myeconfargs=(
# $(use_with qt4)
# $(use_enable threads multithreading)
# $(use_with tiff)
# )
# autotools-utils_src_configure
# }
#
# src_install() {
# autotools-utils_src_install
# if use examples; then
# dobin "${AUTOTOOLS_BUILD_DIR}"/foo_example{1,2,3} \\
# || die 'dobin examples failed'
# fi
# }
#
# @CODE
# Keep variable names synced with cmake-utils and the other way around!
case ${EAPI:-0} in
2|3|4) ;;
*) DEPEND="EAPI-TOO-OLD" ;;
esac
inherit autotools base
EXPORT_FUNCTIONS src_prepare src_configure src_compile src_install src_test
# @ECLASS-VARIABLE: AUTOTOOLS_BUILD_DIR
# @DESCRIPTION:
# Build directory, location where all autotools generated files should be
# placed. For out of source builds it defaults to ${WORKDIR}/${P}_build.
# @ECLASS-VARIABLE: AUTOTOOLS_IN_SOURCE_BUILD
# @DESCRIPTION:
# Set to enable in-source build.
# @ECLASS-VARIABLE: AUTOTOOLS_KEEP_LA_FILES
# @DESCRIPTION:
# Do not remove libtool files.
# @ECLASS-VARIABLE: ECONF_SOURCE
# @DESCRIPTION:
# Specify location of autotools' configure script. By default it uses ${S}.
# @ECLASS-VARIABLE: myeconfargs
# @DESCRIPTION:
# Optional econf arguments as Bash array. Should be defined before calling
src_configure.
# @CODE
# src_configure() {
# myeconfargs=(
# --disable-readline
# --with-confdir="/etc/nasty foo confdir/"
# $(use_enable debug cnddebug)
# $(use_enable threads multithreading)
# )
# autotools-utils_src_configure
# }
# @CODE
# Determine using IN or OUT source build
_check_build_dir() {
: ${ECONF_SOURCE:=${S}}
if [[ -n ${AUTOTOOLS_IN_SOURCE_BUILD} ]]; then
AUTOTOOLS_BUILD_DIR="${ECONF_SOURCE}"
else
: ${AUTOTOOLS_BUILD_DIR:=${WORKDIR}/${P}_build}
fi
echo ">>> Working in BUILD_DIR: \"$AUTOTOOLS_BUILD_DIR\""
}
# @FUNCTION: autotools-utils_src_prepare
# @DESCRIPTION:
# The src_prepare function, supporting PATCHES array and user patches.
# See base.eclass(5) for reference.
autotools-utils_src_prepare() {
debug-print-function $FUNCNAME "$@"
# TODO Maybe some smart patching and automatic eautoreconf call?
base_src_prepare
}
# @FUNCTION: autotools-utils_src_configure
# @DESCRIPTION:
# The src_configure function. For out of source build it creates build
# directory and runs econf there. Configuration parameters defined
# in myeconfargs are passed here to econf. Additionally following USE
# flags are known:
#
# IUSE="debug" passes --disable-debug/--enable-debug to econf respectively.
#
#
[gentoo-dev] QA last rites for media-video/w3cam
# Diego E. Pettenò (26 May 2010) # on behalf of QA team # # Fails to build since at least November 2008, improper # dependencies over freetype, bug #247917. # # Removal on 2010-07-25 media-video/w3cam
[gentoo-dev] QA last rites for dev-lisp/cl-smtp; dev-lisp/cl-pop
# Diego E. Pettenò (26 May 2010) # on behalf of QA team # # cl-smtp fails to fetch since at least September 2007 # (bug #193627); cl-pop needs the former. # # Removal on 2010-07-25 dev-lisp/cl-smtp dev-lisp/cl-pop
Re: [gentoo-dev] Re: [Survey || RFC] autotools-utils.eclass
On Wednesday 26 May 2010 05:38:00 Maciej Mrozowski wrote: > I've updated documentation, added example usage and option to keep libtool > files (ltdl.so supposedly needs those as I was told, no idea what for). more applicable to us w/Linux is that static linking with libtool needs them. the AUTOTOOLS_KEEP_LA_FILES seems kind of spurious considering current tree behavior and assumption of gnu-capable linking systems. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: bug wrangler queue is large...
On Wed, May 26, 2010 at 9:27 AM, Duncan <1i5t5.dun...@cox.net> wrote: > Jeroen Roovers posted on Wed, 26 May 2010 05:08:44 +0200 as excerpted: > >> 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. :) > > I've often wished there was a way to flag a bug as "I'm not thru messing > with it yet, don't mail anyone yet." That's especially true when I know > I'm going to be attaching 2-3 addition files, emerge --info, build log, > maybe sth else like a config file or even a patch, where I know the > wranglers are going to get all those extra mails. Interesting, on most newer ticketing systems I've seen if you are about to make a change there is typically some kind of UI element (checkbox) that says something like 'suppress notifications.' An oft-used feature by me anyway when making cosmetic changes or making a number of changes at once. This assumes of course that anyone interested in the bug will actually visit it to see the full set of updates; not always the care for me and I imagine other users as well. -A > > Or, if there was a way to attach files as part of the initial filing, but > if there is, I've not found it. > > Alternatively, for normal bugs at least, maybe attaching emerge --info can > be made a part of the process, with the post-submit note saying the bug > won't be reported until that second step. (Then for bugs that clearly > don't need it, where the bug's clearly in an initscript or something, have > a checkbox on that second step saying "emerge --info shouldn't be needed > for this.") That would both encourage emerge --info submission AND > prevent one layer of bug spam at the same time! =:^) > > -- > 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] Re: bug wrangler queue is large...
On Wed, 26 May 2010 09:27:08 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > I've often wished there was a way to flag a bug as "I'm not thru > messing with it yet, don't mail anyone yet." That's especially true > when I know I'm going to be attaching 2-3 addition files, emerge > --info, build log, maybe sth else like a config file or even a patch, > where I know the wranglers are going to get all those extra mails. "If the reporter hasn't fulfilled these requirements, the bug should be marked ASSIGNED to bug-wranglers, and a full build log should be requested from the reporter."[1] I've taken to alternatively closing bugs as NEEDINFO lately, e.g. when there is a grave lack of (legible) information, or when output printed by the bug reporter suggests attaching specific files and this isn't done in a timely manner, simply to encourage _reading_ the output instead of simply copy/pasting it. > Or, if there was a way to attach files as part of the initial filing, > but if there is, I've not found it. You usually get a couple of minutes to hours before any wrangling happens. Regards, jer [1] http://www.gentoo.org/proj/en/qa/bug-wranglers/index.xml
Re: [gentoo-dev] QA last rites for dev-lisp/cl-smtp; dev-lisp/cl-pop
Diego E. Pettenò dixit (2010-05-26, 14:54): > > # Diego E. Pettenò (26 May 2010) > # on behalf of QA team > # > # cl-smtp fails to fetch since at least September 2007 > # (bug #193627); cl-pop needs the former. > # > # Removal on 2010-07-25 > dev-lisp/cl-smtp > dev-lisp/cl-pop cl-smtp has just fetched perfectly for me using the ebuild in the lisp overlay... May I humbly suggest a bump instead of treecleaning? On the other hand – I think most CL packages should either get dumped from gentoo proper and people should be advised to use the overlay for most their CL needs today or the overlay should make its way into the main portage tree. Please note that this is just a user's POV – I may not be aware of some important reasons for keeping the somewhat sorry status quo. Best, -- [a]
[gentoo-dev] cmake-utils.eclass updated
Changes: - use DOCS and HTML_DOCS support from base.eclass (arrays), provide backward compatibility code - remove documentation of internal functions so that only relevant and public API is in manual So in short, when using cmake-utils, please from now on define DOCS and HTML_DOCS as arrays as opposite to whitespace separated string. http://sources.gentoo.org/eclass/cmake-utils.eclass?r1=1.51&r2=1.52 -- regards MM
