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
[gentoo-dev] Re: Marking bugs for bugday?
On Sat, 27 Feb 2010 05:18:39 +0100 Sebastian Pipping 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] Marking bugs for bugday?
Ben de Groot 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
Re: [gentoo-dev] Marking bugs for bugday?
On 27 February 2010 21:48, Mark Loeser wrote: > Roy Bamford 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?
chrome://messenger/locale/messengercompose/composeMsgs.properties: Sorry, what's "tlc"? Next Saturday is a bugday date again, btw. Sebastian Tender Loving Care. Dale :-) :-)
Re: [gentoo-dev] Marking bugs for bugday?
Roy Bamford 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 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?
On 2010.02.27 17:38, Sebastian Pipping wrote: [snip] > 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 > Sebastian, What would be the criteria for marking a bug as bugday? Why whould it be any better than a properly maintained bugday.gentoo.org page, which also tried to classify bugs. 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. -- Regards, Roy Bamford (Neddyseagoon) an member of gentoo-ops forum-mods trustees pgptyplfBCzz7.pgp Description: PGP signature
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 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?
Sebastian Pipping 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 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] [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 # Author: Donnie Berkholz # @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##*-
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 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