Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/zzuf: ChangeLog zzuf-0.13.ebuild
On Fri, 26 Feb 2010 23:48:32 +0100 Patrick Lauer patr...@gentoo.org wrote: And I'd appreciate it if PMS would stop refusing to document FEATURES. (Double negative? I mean: PMS should document reality) PMS does document reality: FEATURES can't be used by ebuilds since its values aren't reliable. Tests have to be made for the thing that actually causes the problem, not a variable that indicates that the user requested but may not have been given the thing that causes the problem. But then, we've had this discussion before, and you already know that, so you're just trying to stir up trouble again. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] New eclass for x11 packages
Ok,
as per discussion with remi i slightly updated the eclassdoc and renamed
snapshot variable into saner XORG_EAUTORECONF.
Everything is eclassdoced so it will show up on man xorg-2.eclass when
in main tree.
Does it fit your needs?
Tom
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
#
# @ECLASS: xorg-2.eclass
# @MAINTAINER:
# x...@gentoo.org
# Author: Tomáš Chvátal scarab...@gentoo.org
# Author: Donnie Berkholz dberkh...@gentoo.org
# @BLURB: Reduces code duplication in the modularized X11 ebuilds.
# @DESCRIPTION:
# This eclass makes trivial X ebuilds possible for apps, fonts, drivers,
# and more. Many things that would normally be done in various functions
# can be accessed by setting variables instead, such as patching,
# running eautoreconf, passing options to configure and installing docs.
#
# All you need to do in a basic ebuild is inherit this eclass and set
# DESCRIPTION, KEYWORDS and RDEPEND/DEPEND. If your package is hosted
# with the other X packages, you don't need to set SRC_URI. Pretty much
# everything else should be automatic.
GIT_ECLASS=
if [[ ${PV} == ** ]]; then
GIT_ECLASS=git
XORG_EAUTORECONF=yes
SRC_URI=
fi
# If we're a font package, but not the font.alias one
FONT_ECLASS=
if [[ ${PN} == font* \
${CATEGORY} = media-fonts \
${PN} != font-alias \
${PN} != font-util ]]; then
# Activate font code in the rest of the eclass
FONT=yes
FONT_ECLASS=font
fi
inherit eutils base libtool multilib toolchain-funcs flag-o-matic autotools \
${FONT_ECLASS} ${GIT_ECLASS}
EXPORTED_FUNCTIONS=src_unpack src_compile src_install pkg_postinst pkg_postrm
case ${EAPI:-0} in
3) EXPORTED_FUNCTIONS=${EXPORTED_FUNCTIONS} src_prepare src_configure
;;
*) DEPEND=EAPI-UNSUPPORTED ;;
esac
# exports must be ALWAYS after inherit
EXPORT_FUNCTIONS ${EXPORTED_FUNCTIONS}
IUSE=
HOMEPAGE=http://xorg.freedesktop.org/;
# @ECLASS-VARIABLE: XORG_EAUTORECONF
# @DESCRIPTION:
# If set to 'yes' and configure.ac exists, eautoreconf will run. Set
# before inheriting this eclass.
: ${XORG_EAUTORECONF:=no}
# Set up SRC_URI for individual modular releases
BASE_INDIVIDUAL_URI=http://xorg.freedesktop.org/releases/individual;
# @ECLASS-VARIABLE: MODULE
# @DESCRIPTION:
# The subdirectory to download source from. Possible settings are app,
# doc, data, util, driver, font, lib, proto, xserver. Set above the
# inherit to override the default autoconfigured module.
if [[ -z ${MODULE} ]]; then
MODULE=
case ${CATEGORY} in
app-doc) MODULE=doc ;;
media-fonts) MODULE=font;;
x11-apps|x11-wm) MODULE=app ;;
x11-misc|x11-themes) MODULE=util;;
x11-drivers) MODULE=driver ;;
x11-base)MODULE=xserver ;;
x11-proto) MODULE=proto ;;
x11-libs)MODULE=lib ;;
esac
fi
if [[ -n ${GIT_ECLASS} ]]; then
EGIT_REPO_URI=git://anongit.freedesktop.org/git/xorg/${MODULE}/${PN}
else
SRC_URI+= ${BASE_INDIVIDUAL_URI}/${MODULE}/${P}.tar.bz2
fi
: ${SLOT:=0}
# Set the license for the package. This can be overridden by setting
# LICENSE after the inherit. Nearly all FreeDesktop-hosted X packages
# are under the MIT license. (This is what Red Hat does in their rpms)
: ${LICENSE=MIT}
# Set up shared dependencies
if [[ ${XORG_EAUTORECONF} != no ]]; then
DEPEND+=
=sys-devel/libtool-2.2.6a
sys-devel/m4
# This MUST BE STABLE
[[ ${PN} == util-macros ]] || DEPEND+= =x11-misc/util-macros-1.5.0
WANT_AUTOCONF=latest
WANT_AUTOMAKE=latest
fi
if [[ ${FONT} == yes ]]; then
# This MUST BE STABLE
[[ ${PN} != font-util ]] DEPEND+=
=media-fonts/font-util-1.1.1-r1
RDEPEND+= media-fonts/encodings
x11-apps/mkfontscale
x11-apps/mkfontdir
PDEPEND+= media-fonts/font-alias
# @ECLASS-VARIABLE: FONT_DIR
# @DESCRIPTION:
# If you're creating a font package and the suffix of PN is not equal to
# the subdirectory of /usr/share/fonts/ it should install into, set
# FONT_DIR to that directory or directories. Set before inheriting this
# eclass.
[[ -z ${FONT_DIR} ]] FONT_DIR=${PN##*-}
# Fix case of font directories
FONT_DIR=${FONT_DIR/ttf/TTF}
FONT_DIR=${FONT_DIR/otf/OTF}
FONT_DIR=${FONT_DIR/type1/Type1}
FONT_DIR=${FONT_DIR/speedo/Speedo}
# Set up configure options, wrapped so ebuilds can override if need be
[[ -z ${FONT_OPTIONS} ]]
FONT_OPTIONS=--with-fontdir=\${EPREFIX}/usr/share/fonts/${FONT_DIR}\
[[ ${PN##*-} = misc || ${PN##*-} = 75dpi || ${PN##*-} = 100dpi ||
${PN##*-} = cyrillic ]] IUSE+= nls
fi
# If we're a
Re: [gentoo-dev] Marking bugs for bugday?
On 2010.02.27 04:18, Sebastian Pipping wrote: Hello! I'm surprised that there is no keyword in Gentoo's bugzilla [1] to mark bugs for bugday. Is there a good reason why such a keyword does not exist? Would it be hard to set up? Thanks, Sebastian [1] https://bugs.gentoo.org/describekeywords.cgi Sebastian, That sounds good. If it were an enumerated type bugs could be graded for bugday too. .e.g. Novice You need to have fixed a few Intermediate We don't have a clue. I'm not suggesting any grades - those are just for illustration. -- Regards, Roy Bamford (Neddyseagoon) an member of gentoo-ops forum-mods trustees pgpiYL8TSYAcY.pgp Description: PGP signature
Re: [gentoo-dev] Marking bugs for bugday?
Sebastian Pipping sp...@gentoo.org said: Hello! I'm surprised that there is no keyword in Gentoo's bugzilla [1] to mark bugs for bugday. Is there a good reason why such a keyword does not exist? Would it be hard to set up? I think the goal was to have http://bugday.gentoo.org/ fill this role instead of polluting bugzie with more keywords. I'm not really attached to one approach over the other, but atleast this little site gives the users one place to have to check for things and we can categorize them easily. -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com
Re: [gentoo-dev] Marking bugs for bugday?
On 02/27/10 17:22, Mark Loeser wrote: I think the goal was to have http://bugday.gentoo.org/ fill this role whenever i visit bugday.gentoo.org it takes minutes to load. afair for the two bugdays i participated it didn't display anything helpful (to me), especially: why does it show fixed bugs, too? about half of them are fixed. section new, requests for ebuilds, or just a version bump doesn't have a single bug after 2006, that's how new it is. instead of polluting bugzie with more keywords. would a single keyword be pollution? I'm not really attached to one approach over the other, but atleast this little site gives the users one place to have to check for things and we can categorize them easily. what i see as an advantage of the bugzilla-keyword approach is that any developer can contribute: everyone (especially bug wranglers) can mark bugs for bugday easily from bugzilla. bugday.gentoo.org could still be used as an entry point showing these bugs. sebastian
Re: [gentoo-dev] Marking bugs for bugday?
On 02/27/10 16:39, Roy Bamford wrote: That sounds good. If it were an enumerated type bugs could be graded for bugday too. .e.g. Novice You need to have fixed a few Intermediate We don't have a clue. I'm not suggesting any grades - those are just for illustration. I had that idea too and found it not too helpful. Potential issues: - Difficulity can be very subjective - Introducing new levels later doesn't work well as we'd manually have to go through each bug left or right of that new level. So we'd have to get it very right the first time. Sebastian
Re: [gentoo-dev] Marking bugs for bugday?
On 02/27/10 19:14, Roy Bamford wrote: What would be the criteria for marking a bug as bugday? I would say something along a yes to Could this task fit for being solved by someone who is not a Gentoo developer? It's not precise, does it need to be? Why whould it be any better than a properly maintained bugday.gentoo.org page, which also tried to classify bugs. As I said: with this keyword every Gentoo dev can help classifying. Lower risk on bottlenecks/delays and manpower. The last few times I've dropped into bugday, its been very quiet, which suggests its in need of some tlc but maybe its just my timezone. Sorry, what's tlc? Next Saturday is a bugday date again, btw. Sebastian
Re: [gentoo-dev] Marking bugs for bugday?
Roy Bamford neddyseag...@gentoo.org said: The last few times I've dropped into bugday, its been very quiet, which suggests its in need of some tlc but maybe its just my timezone. Its been pretty much dead. We need more developer involvement so users can actually talk to them and help resolve issues. If we can't get enough developers to participate then we should just stop trying to do it instead of putting on such a poor showing. -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com
Re: [gentoo-dev] Marking bugs for bugday?
On 27 February 2010 21:48, Mark Loeser halc...@gentoo.org wrote: Roy Bamford neddyseag...@gentoo.org said: The last few times I've dropped into bugday, its been very quiet, which suggests its in need of some tlc but maybe its just my timezone. Its been pretty much dead. We need more developer involvement so users can actually talk to them and help resolve issues. If we can't get enough developers to participate then we should just stop trying to do it instead of putting on such a poor showing. I would like to be involved but not in the current disorganized form. Our #gentoo-bugs channel topic still refers to the thoroughly outdated bugsday.g.o page, and I can't edit either of them. We need an easier interface to mark bugs to be tackled on bugday, and I like Sebastian's proposal for that. The idea for the bugsday.g.o page is good, but it needs to be brought up-to-date and accessible to all devs. Low barriers to participation and all that. And even devs who cannot take part on the day itself could participate by requesting certain bugs or issues to be tackled. Also, participating devs should get permission to commit easy fixes for packages they don't maintain (the other thread about commit policies is relevant here). Obviously issues that are more involved need to be passed on to the proper maintainers. I think if we can get a few devs and possibly some users together to organize this in a better way, this could be useful. But if things are to stay the way they are, then we better stop pretending. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] Marking bugs for bugday?
Ben de Groot yng...@gentoo.org said: Its been pretty much dead. We need more developer involvement so users can actually talk to them and help resolve issues. If we can't get enough developers to participate then we should just stop trying to do it instead of putting on such a poor showing. I would like to be involved but not in the current disorganized form. Our #gentoo-bugs channel topic still refers to the thoroughly outdated bugsday.g.o page, and I can't edit either of them. I can modify the channel topic for you. I should have a login for the bugsday.g.o page somewhere, if not...I'm sure we can get one. We need an easier interface to mark bugs to be tackled on bugday, and I like Sebastian's proposal for that. The idea for the bugsday.g.o page is good, but it needs to be brought up-to-date and accessible to all devs. Low barriers to participation and all that. And even devs who cannot take part on the day itself could participate by requesting certain bugs or issues to be tackled. If you want to take the lead on this, come and talk to me on IRC and let me know what ideas you have. I'd love to see it take off, but I don't have the time to put towards it myself. Also, participating devs should get permission to commit easy fixes for packages they don't maintain (the other thread about commit policies is relevant here). Obviously issues that are more involved need to be passed on to the proper maintainers. This is something we'll have to be careful of and discuss what types of changes can be done. Not everything needs to be necessarily fixed in the tree though, helping users get proper patches onto bugs can be just as good and help get more useful contributions from those users in the future. Consider it an opportunity to train possible new developers. I think if we can get a few devs and possibly some users together to organize this in a better way, this could be useful. But if things are to stay the way they are, then we better stop pretending. I couldn't agree more. -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com
[gentoo-dev] Re: Marking bugs for bugday?
On Sat, 27 Feb 2010 05:18:39 +0100 Sebastian Pipping sp...@gentoo.org wrote: I'm surprised that there is no keyword in Gentoo's bugzilla [1] to mark bugs for bugday. Is there a good reason why such a keyword does not exist? Would it be hard to set up? I would use it. I honestly didn't know we still did bugdays. :/ -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Brief downtime @ 19:45 UTC TODAY of: crane, duck, hawk, pheasant, raven
On 02/25/2010 11:32 AM, Robin H. Johnson wrote: Sorry for the short notice, but the boxes as noted above are going to have some brief downtime in the next hour for IP renumbering. It will briefly take out the anonvcs service, as well as a lot of rsync.g.o capacity. Total downtime should be less than 20 minutes. The anonsvn portage repo has been stuck rev 15458 since Thursday, possibly related to the IP renumbering. -- Thanks, Zac
Re: [gentoo-portage-dev] Composite exceptions?
Good idea, thank you! Sebastian
