Re: [gentoo-dev] architectures which support Java
On Thursday 20 July 2006 21:17, Joshua Nichols wrote: > Could I get notice of whether or not your architecture is supporting > Java? On PPC64 we have support for java in theory. In IBM JDK version 1.4 the Java JIT compiler is broken, so pretty much everything is broken - except things that are just run and not compiled.. (you have to "export JAVA_COMPILER=none") Version 1.5 on the other side does work pretty good. So add PPC64 to the list of supported arches once 1.5 is stable ;-) Regards, Markus pgpHDwGD6wTTh.pgp Description: PGP signature
Re: [gentoo-dev] architectures which support Java
On Thursday 20 July 2006 17:17, Joshua Nichols wrote: > Could I get notice of whether or not your architecture is supporting > Java? in Gentoo or in general ? in general, kaffe should support pretty much all our arches, but in Gentoo, i dont have time to get it working for: arm m68k s390 sh -mike pgp6VLiMZDkKI.pgp Description: PGP signature
Re: [gentoo-dev] architectures which support Java
On Thursday 20 July 2006 23:17, Joshua Nichols wrote: > Supports: > amd64 > ppc > x86 Work-in-progress: ~x86-fbsd (diablo-jre-bin in tree, waiting for Timothy to give me the ebuild for diablo-jdk and then we'll be all set). -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpKakFYAEb2W.pgp Description: PGP signature
Re: [gentoo-dev] Einput eclass
John Jawed wrote: > Below is a link to an "enhanced input" eclass as well as a screenshot. > This eclass was made to simplify interacting with the user at > pkg_config(). > > http://jawed.name/dev/gentoo/einput.eclass > http://jawed.name/dev/gentoo/einput.png (code used to create this > output is below) > > This eclass started off as a small set of scripts used by academia at > my current campus and eventually was built upon. I was the original > author and modified it later to be ebuild friendly. It has support for > serial consoles. > > The main purpose of this eclass is to make life simpler for developers > that try to streamline --config interaction. For example, having > --config with net-proxy/squid may ask for where to create the swap > directories, sed the config and then issue a squid -z for the user. > Taking it further, it may ask if the user wants the --config to add > the runlevel init scripts. Upgrades to packages which require > conversion of data catalogs (such as MySQL/PostgreSQL data > directories) could also be streamlined with user interaction. > > In general, I think having more post install configurations to > streamline the basics for core > packages will be beneficial to both Gentoo newcomers and gurus. The > einput.eclass should help Gentoo developers lives easier in achieving > in that goal. > > I would like to continue to build upon this eclass. > > Regards, > John John, I think you've done a really great job with this. Very creative and good initiative. You're hired. Someone get him his developer badge.. -- Doug Goldstein <[EMAIL PROTECTED]> http://dev.gentoo.org/~cardoe/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New category: net-voip
On Thursday 20 July 2006 22:24, Brian Harring wrote: > err... > emerge -s > pquery > paludis -q Or for people into Web 2.0: http://packages.gentoo.org/search/?sstring= (that is what I use usually, having aliased pgo: to that in konqueror ;) ). -- Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp6MCIKDUbuy.pgp Description: PGP signature
Re: [gentoo-dev] New category: net-voip
On Thu, 2006-07-20 at 13:24 -0700, Brian Harring wrote: > Not much experience then. Your use scenario above is "I'm looking > for a package", not "I'm trying to find packages in category x". > > Of course categories don't matter to you in your case- you're not > *using* them. What others are talking about how ever is folks who > *are* using categories- say to see if any new packages were added to > games-strategy. Actually, this is a perfect example of categories working properly. After all, if you like to play the occasional RPG, then games-rpg would be where you'd want to look. Sure, some of them are graphical and require X, meaning they *could* be in x11-apps, but that isn't what most people would consider them first. That being said, if you were wanting, say, Neverwinter Nights (nwn), then it is possible you wouldn't know which category it resides in, and need to search for it. However, saying that categories in portage are poorly implemented is pretty much downplaying their usefulness. If someone told me there's a bug in ipw2200, I might not know what that would be. If someone told me there's a bug in net-wireless/ipw2200, I definitely would know that it is some sort of wireless driver/application. Sure, we all know that the categories in portage aren't perfect, but they're pretty good, for most cases. > > How to categorise is critical, if they are to have any meaning to > > users. > > Even if a pkg is slightly miscategorized, it still is a fair bit more > useful then having a flat namespace. Agreed. Let's look at something like dhcpcd. It resides in net-misc. Now, without that category, who would know it has *anything* to do with networking (assuming you don't know what DHCP is... :P)? Of course, that isn't the best example, but it does show the point. > > If you want to see if a package is in the tree, do you go > > straight to it, or do you find yourself doing things like: > > > > ls -d /usr/portage/*/* > > > > to find it? > > err... > emerge -s > pquery > paludis -q > > I'm honestly not really sure what point you're making there. I find myself first doing "emerge $packagename" since that *usually* works. ;] After that, I'll resort to some method of searching. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Einput eclass
There are two ebuilds which use this currently:
http://jawed.name/dev/gentoo/openfts-0.39.ebuild
http://jawed.name/dev/gentoo/dev-db/pgfouine/pgfouine-0.6.ebuild
The code used to generate the screenshot got lost in the initial
posting, here it is:
pkg_config() {
displayListPrompt "1" "List Entry" "2" "List File" "Choose a listing
style"
einfo
displayConfirmPrompt "Are you sure you want to rm -rf /?"
einfo
displayQuestionPrompt "Is Gentoo a good Linux distro?" "Yes it is Jim"
einfo
displaySQuestionPrompt "Please enter your root password"
}
On 7/20/06, Luca Longinotti <[EMAIL PROTECTED]> wrote:
I'm willing to put this eclass in the tree and maintain it myself for now, and
when John
become a full Gentoo dev (this is already scheduled, he'll help out on
PostgreSQL related stuff in the near future), he can take it over
directy... Any objections to this wandering into the tree?
Thanks Luca!
On 7/20/06, Brian Harring <[EMAIL PROTECTED]> wrote:
Examples of converted ebuilds would be wise prior to plopping it into
the tree imo- fex, displayConfirmPrompt looks like it should be
reliant on exit codes rather then mangling a global var to indicate
the outcome; that would shift it more towards "get confirmation"
rather then display.
Makes much more sense, I will get to work on converting those to exit codes.
Regards,
John
"Open source, you don't pay back, you pay forward."
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] architectures which support Java
Attention arch team types: Could I get notice of whether or not your architecture is supporting Java? The question comes out occaisonally, and it's a little embarassing for me when I don't the status for a particular arch and its Java support. So please, help me get in the loop :) I'd like to post this info somewhere on our project page [1] These are the archs I specifically know about: Supports: amd64 ppc x86 Doesn't support: alpha hppa sparc [1] http://www.gentoo.org/proj/en/java/ Thanks, - Josh -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Einput eclass
On Thu, Jul 20, 2006 at 09:39:14PM +0200, Luca Longinotti wrote:
> John Jawed wrote:
> > Below is a link to an "enhanced input" eclass as well as a screenshot.
> > This eclass was made to simplify interacting with the user at
> > pkg_config().
>
> This is a good idea imo, it could really simplify and help with
> pkg_config stuff, think of dev-db/mysql or others who need to ask
> questions, passwords etc., this would help doing that in a simple,
> standardized way. Maintainance is no problem, I'm willing to put this
> eclass in the tree and maintain it myself for now, and when John will
> become a full Gentoo dev (this is already scheduled, he'll help out on
> PostgreSQL related stuff in the near future), he can take it over
> directy... Any objections to this wandering into the tree? Suggestions,
> ideas? Thanks!
Examples of converted ebuilds would be wise prior to plopping it into
the tree imo- fex, displayConfirmPrompt looks like it should be
reliant on exit codes rather then mangling a global var to indicate
the outcome; that would shift it more towards "get confirmation"
rather then display.
Hence Why I think examples would be useful- eclass api can only be
extended once it's in the tree. I'd go and build up consumers of the
eclass to
A) show off
B) find the weak spots in your eclass api _now_ rather then having to
do an einput{1..N}.eclass
Aside from that, not sure about the RC_NOCOLOR fiddling in initInput-
haven't checked, but that should be handled by ebuild.sh already via
the profile sourcing.
~harring
pgpRut6ZyyHTe.pgp
Description: PGP signature
Re: [gentoo-dev] New category: net-voip
On Thu, Jul 20, 2006 at 08:41:46PM +0200, Kevin F. Quinn wrote: > On Thu, 20 Jul 2006 00:37:47 -0700 > Brian Harring <[EMAIL PROTECTED]> wrote: > > > On Thu, Jul 20, 2006 at 09:05:03AM +0200, Kevin F. Quinn wrote: > > > On Wed, 19 Jul 2006 17:15:38 +0100 > > > Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > > > > > > > On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn" > > > > <[EMAIL PROTECTED]> wrote: > > > > | Things that package moves cause: > > > > | 1) Dependencies throughout the tree have to be updated > > > > > > > > And? This isn't a breakage. > > > > > > It is however unnecessary inconvenience for the user, even assuming > > > the support for moves is bug-free. > > > > Think you're ignoring that proper categorization *is* useful to the > > user. One of the costs of that is moving when necessary. > > My main point is that "proper" categorisation is subjective. What > should be in net-voip for some people, should be in net-im for others > (since many packages provide functionality in both areas). Thus whether > or not it moves are necessary is subjective. How often does a package lie equally across multiple categories? I think your point (pulling probably fairly close figures out of the head) is relevant to all of 100 or so packages in the tree, out of 11k. > > Sounds of it, you don't much care for categorizatin- that's fine, > > please keep in mind some people do find it a net gain to maintain the > > categorization however. > > I'm happy with the idea of categorisation in general, I do however think > that the categorisation in the tree as it stands is simply inadequate. Examples would be lovely- numerous examples specifically. Please keep in mind the tree holds (as of about 15 hours back) 11,212 packages. Pointing at one or two packages to label all categorization as inadequate won't suffice, going to need to clear at *least* 1% of the tree to back that assertion up. > > > > | 3) Binary packages go out-of-date > > > > > > > > So rebuild them. Binary packages go out of date whenever someone > > > > does a version bump too. > > > > > > So your opinion is that it's fine to cause users to rebuild stuff > > > even when the package itself hasn't changed? > > > > You're ignoring what fixpackages does. Ever noticed how it's far > > faster when you don't have buildpkgs enabled? ;) > > I certainly noticed how much time is lost when fixpackages chunters > through built packages to fix stuff up. My usual response to criticism of that sort applies- you know where the src is ;) Doing things *correctly* isn't always the same as doing things *fast*. Throwing correctness bits out in the name of speed is a no go (iow, fixpackages ought to be nonoptional). > > Again, you may not view categories as useful, but others may. > > My experience with categories as they stand, is that to find a package > whose location I don't already know I have to search all categories > anyway - it's certainly not possible to predict in which category a > package lives. Not much experience then. Your use scenario above is "I'm looking for a package", not "I'm trying to find packages in category x". Of course categories don't matter to you in your case- you're not *using* them. What others are talking about how ever is folks who *are* using categories- say to see if any new packages were added to games-strategy. > > > > So again, you've *not* given any reasons to avoid sensible package > > > > moves. > > > > > > Ah; now you're qualifying. What do you consider to be a sensible > > > package move? I would define it as moves where the package is > > > blatantly in the wrong category (e.g. a voip package being found in > > > the app-text category) rather than moves where the package might be > > > a little more appropriate for one category than another - > > > especially where that judgement is subjective. > > > > Arguement over how to categorize I'll gladly stay out of, although > > one comment- for pkgs that are (at the initial time of adding) one of > > a kind, creating a category for it's specific flavor doesn't make > > much sense. > > How to categorise is critical, if they are to have any meaning to > users. Even if a pkg is slightly miscategorized, it still is a fair bit more useful then having a flat namespace. > If you want to see if a package is in the tree, do you go > straight to it, or do you find yourself doing things like: > > ls -d /usr/portage/*/* > > to find it? err... emerge -s pquery paludis -q I'm honestly not really sure what point you're making there. ~harring pgpnCBqQOyGxb.pgp Description: PGP signature
Re: [gentoo-dev] Einput eclass
John Jawed wrote: > Below is a link to an "enhanced input" eclass as well as a screenshot. > This eclass was made to simplify interacting with the user at > pkg_config(). This is a good idea imo, it could really simplify and help with pkg_config stuff, think of dev-db/mysql or others who need to ask questions, passwords etc., this would help doing that in a simple, standardized way. Maintainance is no problem, I'm willing to put this eclass in the tree and maintain it myself for now, and when John will become a full Gentoo dev (this is already scheduled, he'll help out on PostgreSQL related stuff in the near future), he can take it over directy... Any objections to this wandering into the tree? Suggestions, ideas? Thanks! -- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: [EMAIL PROTECTED] Gentoo Dev: [EMAIL PROTECTED] SysCP Dev: [EMAIL PROTECTED] TILUG Supporter: [EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New category: net-voip
On Thu, 20 Jul 2006 00:37:47 -0700 Brian Harring <[EMAIL PROTECTED]> wrote: > On Thu, Jul 20, 2006 at 09:05:03AM +0200, Kevin F. Quinn wrote: > > On Wed, 19 Jul 2006 17:15:38 +0100 > > Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > > > > > On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn" > > > <[EMAIL PROTECTED]> wrote: > > > | Things that package moves cause: > > > | 1) Dependencies throughout the tree have to be updated > > > > > > And? This isn't a breakage. > > > > It is however unnecessary inconvenience for the user, even assuming > > the support for moves is bug-free. > > Think you're ignoring that proper categorization *is* useful to the > user. One of the costs of that is moving when necessary. My main point is that "proper" categorisation is subjective. What should be in net-voip for some people, should be in net-im for others (since many packages provide functionality in both areas). Thus whether or not it moves are necessary is subjective. > Sounds of it, you don't much care for categorizatin- that's fine, > please keep in mind some people do find it a net gain to maintain the > categorization however. I'm happy with the idea of categorisation in general, I do however think that the categorisation in the tree as it stands is simply inadequate. > > > | 2) Current installations become inconsistent with respect to the > > > tree > > > > > > Uh, current installations become 'inconsistent' whenever anyone > > > changes *anything* in the tree. > > > > To a different degree. In the package move case, the inconsistency > > occurs even though nothing has really changed, in terms of what the > > packages actually do. > > Fundamentally the same thing however. It's metadata changes in the > pkg universe, people fixing missing deps on pkgs induce the same > thing. No, my point was that there are two types of change to the tree - changes that make a functional difference, and changes that don't. Most changes to the tree fall into the former; however package moves fall into the latter. > Thing to note however is that via fixpackages, the inconsistancy can > be corrected (the example I gave above cannot be without a verbump of > some sort). > > > > > | 3) Binary packages go out-of-date > > > > > > So rebuild them. Binary packages go out of date whenever someone > > > does a version bump too. > > > > So your opinion is that it's fine to cause users to rebuild stuff > > even when the package itself hasn't changed? > > You're ignoring what fixpackages does. Ever noticed how it's far > faster when you don't have buildpkgs enabled? ;) I certainly noticed how much time is lost when fixpackages chunters through built packages to fix stuff up. These moves are the main reason I removed buildpkgs from FEATURES. That was a while ago now - Duncun suggests it's a lot faster now but I've not tried it recently. > It goes through and rewrites the dependencies as needed. So no, > doesn't force a rebuild if the user is running with proper options > (frankly an option that should be nonoptional). > > > > > | 4) Increased sync load > > > > > > Not really significant in comparison to, say, an arch team > > > keywording a new KDE or Gnome stable. > > > > The difference with KDE or Gnome going stable is that it actually > > provides something useful; i.e. an updated version of the packages > > that are presumably better in some way. Package moves do not > > improve what the package provides, at all, so you incur the pain > > for no gain. > > Again, you may not view categories as useful, but others may. My experience with categories as they stand, is that to find a package whose location I don't already know I have to search all categories anyway - it's certainly not possible to predict in which category a package lives. > > > | The key issue is that categories are semantically inadequate. > > > > > > That's no reason to use them improperly. > > > > I note you cherry-pick what to respond to. I explained how, without > > improper use (whatever that is), you just end up with a tug-of-war > > between herds about which category something should be in. > > Back hand the herds then. If they want to infight, spank their asses. > > Herds misbehaving doesn't mean everyone else is going to have a > pissing match over the categorization of a pkg however- it shouldn't > be used as an arguement _against_ proper categorization, since idiot > infighting is a whole other problem. > > > > > So again, you've *not* given any reasons to avoid sensible package > > > moves. > > > > Ah; now you're qualifying. What do you consider to be a sensible > > package move? I would define it as moves where the package is > > blatantly in the wrong category (e.g. a voip package being found in > > the app-text category) rather than moves where the package might be > > a little more appropriate for one category than another - > > especially where that judgement is subjective. > > Arguement over how to catego
Re: [gentoo-dev] New category: net-voip
On Thu, 20 Jul 2006 09:05:03 +0200 "Kevin F. Quinn" <[EMAIL PROTECTED]> wrote: | On Wed, 19 Jul 2006 17:15:38 +0100 | Ciaran McCreesh <[EMAIL PROTECTED]> wrote: | > On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn" | > <[EMAIL PROTECTED]> wrote: | > | Things that package moves cause: | > | 1) Dependencies throughout the tree have to be updated | > | > And? This isn't a breakage. | | It is however unnecessary inconvenience for the user, even assuming | the support for moves is bug-free. Eh? The only thing users see is packages where they'd expect them, which is very convenient. | > | 2) Current installations become inconsistent with respect to the | > tree | > | > Uh, current installations become 'inconsistent' whenever anyone | > changes *anything* in the tree. | | To a different degree. In the package move case, the inconsistency | occurs even though nothing has really changed, in terms of what the | packages actually do. Uh, changing KEYWORDS doesn't change what the packages actually do, but it does create an inconsistency. | > | 3) Binary packages go out-of-date | > | > So rebuild them. Binary packages go out of date whenever someone | > does a version bump too. | | So your opinion is that it's fine to cause users to rebuild stuff even | when the package itself hasn't changed? If they're one of the tree people for whom fixpackages is insufficient, then yes. | > | 4) Increased sync load | > | > Not really significant in comparison to, say, an arch team | > keywording a new KDE or Gnome stable. | | The difference with KDE or Gnome going stable is that it actually | provides something useful; i.e. an updated version of the packages | that are presumably better in some way. Package moves do not improve | what the package provides, at all, so you incur the pain for no gain. The gain is a more sensible tree. With the tree as big as it is, that's a very important consideration. | > | 5) Loss of history, unless the move is performed server-side (i.e. | > | extra work for infra) | > | > History's in the ChangeLog. | | That's a fraction of what's in the CVS history, however. Then start persuading people to keep better CHangeLogs. The CVS history is still around for when you really need it, of course. | > | The key issue is that categories are semantically inadequate. | > | > That's no reason to use them improperly. | | I note you cherry-pick what to respond to. I explained how, without | improper use (whatever that is), you just end up with a tug-of-war | between herds about which category something should be in. I'd call it "snipping out things that're irrelevant to the discussion at hand". Your personal dislike of categories has nothing to do with anything. We're talking about the tree and capabilities that're available, not the tree and capabilities you'd like. | > So again, you've *not* given any reasons to avoid sensible package | > moves. | | Ah; now you're qualifying. Well yes. It's to prevent you from countering with an absurd example where package moves are abused. Nobody really thinks we should be doing three hundred package moves every day, but I wouldn't put it past certain people to use an argument based around that to say that all package moves are bad... | What do you consider to be a sensible package move? One that makes the tree more consistent and easier to maintain. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
After mulling it over for a bit I think I could actually do some good here. Plus another name in the hat makes the elections that much more interestingas my campaign pledge I promise to establish a developer juice bar (I tried for the ice cream machine but the lactose intolerance lobby is just too powerful), to extend developer vacations to include alternate Thursdays, and to establish National Larry The Cow Day...my people are still talking to the small transgender cow lobby to pinpoint the exact day/month...you'd be surprised sexual presentation is not the only thing that transgender cows have a hard time making their mind up about. The long and short of it...I accept. --Dan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Nominations open for the Gentoo Council 2007
On Thu, 2006-07-20 at 01:51 -0400, Mike Frysinger wrote: > thanks to solar and yoswink we have a xml version now: > http://dev.gentoo.org/~vapier/council-2006-nominees.xml > > for you peeps who have yet to speak up at all, please do so in the next week, > or i'll start hunting you down when i get back from China :) I've thought about it and I accept the nomination. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Nominations open for the Gentoo Council 2007
On Wed, 2006-07-19 at 23:22 -0700, Tuan Van wrote: > please update above link for rl03 and wolf31o2 ( unless he has changed > his mind). snipped from -core . core isn't archived so I cut&paste the > header here hope it made easier for you to locate those mails These are two different things. The nominations on *this* list are for the Council. The nominations on -core/-nfp are for the Trustees. > , > Subject: Re: [gentoo-nfp] Re: [gentoo-core] Nominations? > From: Chris Gianelloni <[EMAIL PROTECTED]> > To: Grant Goodyear <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > Date: Fri, 07 Jul 2006 07:47:21 -0400 > Message-Id: <[EMAIL PROTECTED]> > > I'm not too interested in becoming a Trustee, unless ... > ` Actually, I'm about to respond to this, since I've reconsidered it, but I'll be doing so on the proper lists. ;] -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
[gentoo-dev] Making openexr global use
current count local use flags (searching: openexr) [-] openexr (dev-games/ogre): support for the openexr file format [-] openexr (kde-base/kdebase-kioslaves): Support for the OpenEXR graphics file format (www.openexr.com). [-] openexr (kde-base/kdebase): Support for the OpenEXR graphics file format (www.openexr.com). [-] openexr (kde-base/kdegraphics-kfile-plugins): Support for the OpenEXR graphics file format (www.openexr.com). [-] openexr (kde-base/kdegraphics): Support for the OpenEXR graphics file format (www.openexr.com). [-] openexr (kde-base/kdelibs): Support for the OpenEXR graphics file format (www.openexr.com). [-] openexr (media-gfx/blender): Adds support for openexr [-] openexr (media-gfx/k3d): build OpenEXR plug-ins [-] openexr (media-gfx/pixie): build OpenEXR display module yafray is getting it too right now. I'll put it as global if nobody shouts otherwise. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Nominations open for the Gentoo Council 2007
Mike Frysinger wrote: > thanks to solar and yoswink we have a xml version now: > http://dev.gentoo.org/~vapier/council-2006-nominees.xml > > for you peeps who have yet to speak up at all, please do so in the next week, > or i'll start hunting you down when i get back from China :) s/when/if/ I noticed someone with a name very close to mine was nominated. I'm not sure about him, but I wouldn't accept it :) Thanks for the nomination. Regards, -- / Xavier Neys \_ Gentoo Documentation Project / /\ http://www.gentoo.org/doc/en/ signature.asc Description: OpenPGP digital signature
[gentoo-dev] Nomination for robbat2 - My issue, getting Gentoo more verifiable via signing
On Sat, Jul 01, 2006 at 02:46:59AM -0400, Mike Frysinger wrote: > well it's about that time of the year ... time for nominating people > for the next Gentoo Council Hi, I know I haven't been around a huge amount lately, I'm getting married in a month, so I've been a bit busy. However I would like to run for Council - with a specific eye towards getting the tree signed and verifiable. I have been working on the issue, and I've got a set of proto-GLEPs that I need to polish off and post up for discussion. For the most part, we're closer to doing it than realized by most, and the work required on the part of each developer isn't large at all. Most importantly, the base part of it is accomplished simply with the collaboration of the Portage crew and Infrastructure - more details to follow soon. I'm not certain if it's good to be a one-issue candidate but adding security to the tree is something that presents a major gain to Gentoo. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgprgy106iCed.pgp Description: PGP signature
Re: [gentoo-dev] New category: net-voip
On Thu, Jul 20, 2006 at 09:05:03AM +0200, Kevin F. Quinn wrote: > On Wed, 19 Jul 2006 17:15:38 +0100 > Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > > > On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn" > > <[EMAIL PROTECTED]> wrote: > > | Things that package moves cause: > > | 1) Dependencies throughout the tree have to be updated > > > > And? This isn't a breakage. > > It is however unnecessary inconvenience for the user, even assuming the > support for moves is bug-free. Think you're ignoring that proper categorization *is* useful to the user. One of the costs of that is moving when necessary. Sounds of it, you don't much care for categorizatin- that's fine, please keep in mind some people do find it a net gain to maintain the categorization however. > > | 2) Current installations become inconsistent with respect to the > > tree > > > > Uh, current installations become 'inconsistent' whenever anyone > > changes *anything* in the tree. > > To a different degree. In the package move case, the inconsistency > occurs even though nothing has really changed, in terms of what the > packages actually do. Fundamentally the same thing however. It's metadata changes in the pkg universe, people fixing missing deps on pkgs induce the same thing. Thing to note however is that via fixpackages, the inconsistancy can be corrected (the example I gave above cannot be without a verbump of some sort). > > | 3) Binary packages go out-of-date > > > > So rebuild them. Binary packages go out of date whenever someone does > > a version bump too. > > So your opinion is that it's fine to cause users to rebuild stuff even > when the package itself hasn't changed? You're ignoring what fixpackages does. Ever noticed how it's far faster when you don't have buildpkgs enabled? ;) It goes through and rewrites the dependencies as needed. So no, doesn't force a rebuild if the user is running with proper options (frankly an option that should be nonoptional). > > | 4) Increased sync load > > > > Not really significant in comparison to, say, an arch team keywording > > a new KDE or Gnome stable. > > The difference with KDE or Gnome going stable is that it actually > provides something useful; i.e. an updated version of the packages that > are presumably better in some way. Package moves do not improve what > the package provides, at all, so you incur the pain for no gain. Again, you may not view categories as useful, but others may. > > | The key issue is that categories are semantically inadequate. > > > > That's no reason to use them improperly. > > I note you cherry-pick what to respond to. I explained how, without > improper use (whatever that is), you just end up with a tug-of-war > between herds about which category something should be in. Back hand the herds then. If they want to infight, spank their asses. Herds misbehaving doesn't mean everyone else is going to have a pissing match over the categorization of a pkg however- it shouldn't be used as an arguement _against_ proper categorization, since idiot infighting is a whole other problem. > > So again, you've *not* given any reasons to avoid sensible package > > moves. > > Ah; now you're qualifying. What do you consider to be a sensible > package move? I would define it as moves where the package is blatantly > in the wrong category (e.g. a voip package being found in the app-text > category) rather than moves where the package might be a little more > appropriate for one category than another - especially where that > judgement is subjective. Arguement over how to categorize I'll gladly stay out of, although one comment- for pkgs that are (at the initial time of adding) one of a kind, creating a category for it's specific flavor doesn't make much sense. Couple of months down the line? # of pkgs that would fall into that categorization may warrant it, a scenario that does occur and is a bit relevant to net-voip. ~harring pgpKRM0NKBb6U.pgp Description: PGP signature
Re: [gentoo-dev] Nominations open for the Gentoo Council 2007
On Thursday 20 July 2006 02:22, Tuan Van wrote: > Mike Frysinger wrote: > > thanks to solar and yoswink we have a xml version now: > > http://dev.gentoo.org/~vapier/council-2006-nominees.xml > > please update above link for rl03 and wolf31o2 ( unless he has changed > his mind). snipped from -core . trustee nominations != council nominations -mike pgp3cobQjU6no.pgp Description: PGP signature
Re: [gentoo-dev] New category: net-voip
On Wed, 19 Jul 2006 17:15:38 +0100 Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Wed, 19 Jul 2006 08:57:32 +0200 "Kevin F. Quinn" > <[EMAIL PROTECTED]> wrote: > | Things that package moves cause: > | 1) Dependencies throughout the tree have to be updated > > And? This isn't a breakage. It is however unnecessary inconvenience for the user, even assuming the support for moves is bug-free. > | 2) Current installations become inconsistent with respect to the > tree > > Uh, current installations become 'inconsistent' whenever anyone > changes *anything* in the tree. To a different degree. In the package move case, the inconsistency occurs even though nothing has really changed, in terms of what the packages actually do. > | 3) Binary packages go out-of-date > > So rebuild them. Binary packages go out of date whenever someone does > a version bump too. So your opinion is that it's fine to cause users to rebuild stuff even when the package itself hasn't changed? > | 4) Increased sync load > > Not really significant in comparison to, say, an arch team keywording > a new KDE or Gnome stable. The difference with KDE or Gnome going stable is that it actually provides something useful; i.e. an updated version of the packages that are presumably better in some way. Package moves do not improve what the package provides, at all, so you incur the pain for no gain. > | 5) Loss of history, unless the move is performed server-side (i.e. > | extra work for infra) > > History's in the ChangeLog. That's a fraction of what's in the CVS history, however. > | The key issue is that categories are semantically inadequate. > > That's no reason to use them improperly. I note you cherry-pick what to respond to. I explained how, without improper use (whatever that is), you just end up with a tug-of-war between herds about which category something should be in. > So again, you've *not* given any reasons to avoid sensible package > moves. Ah; now you're qualifying. What do you consider to be a sensible package move? I would define it as moves where the package is blatantly in the wrong category (e.g. a voip package being found in the app-text category) rather than moves where the package might be a little more appropriate for one category than another - especially where that judgement is subjective. -- Kevin F. Quinn signature.asc Description: PGP signature
[gentoo-dev] Re: Nominations open for the Gentoo Council 2007
* Tuan Van <[EMAIL PROTECTED]>: > Mike Frysinger wrote: > > thanks to solar and yoswink we have a xml version now: > > http://dev.gentoo.org/~vapier/council-2006-nominees.xml > > > please update above link for rl03 and wolf31o2 > , > Date: Fri, 7 Jul 2006 00:30:35 + > From: Renat Lumpau <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: [gentoo-core] Nominations? > Message-ID: <[EMAIL PROTECTED]> > > Oh yes, I accept. > ` > , > Subject: Re: [gentoo-nfp] Re: [gentoo-core] Nominations? > From: Chris Gianelloni <[EMAIL PROTECTED]> > To: Grant Goodyear <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > Date: Fri, 07 Jul 2006 07:47:21 -0400 > Message-Id: <[EMAIL PROTECTED]> > > I'm not too interested in becoming a Trustee, unless ... > ` Council vs. Trustees. These mails were a reply to a (hypothetical?) trustee nomination while Mike's webpage lists nominations for the council. -- gentoo-dev@gentoo.org mailing list
