Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
On 10/03/13 20:04, Jeroen Roovers wrote: On Sun, 3 Mar 2013 12:44:18 +0100 Tomáš Chvátal tomas.chva...@gmail.com wrote: If I remember correctly the damn rule is to put it for 30 days into testing, and as you said there was no previous version on arm so users could've reported some issues, i agree that sometimes you have to ignore the rules to really fix stable, but was this such case for sure? I've done straight to stable keywording _many_ times. The rationale is that with no previous version stable for a particular architecture, there really are no users who could see _regressions_, hence waiting the nominal thirty days is meaningless in this case. agreed, this is how I work too
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
On Sun, 3 Mar 2013 12:44:18 +0100 Tomáš Chvátal tomas.chva...@gmail.com wrote: If I remember correctly the damn rule is to put it for 30 days into testing, and as you said there was no previous version on arm so users could've reported some issues, i agree that sometimes you have to ignore the rules to really fix stable, but was this such case for sure? I've done straight to stable keywording _many_ times. The rationale is that with no previous version stable for a particular architecture, there really are no users who could see _regressions_, hence waiting the nominal thirty days is meaningless in this case. jer
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
On 03/10/2013 07:04 PM, Jeroen Roovers wrote: On Sun, 3 Mar 2013 12:44:18 +0100 Tomáš Chvátal tomas.chva...@gmail.com wrote: If I remember correctly the damn rule is to put it for 30 days into testing, and as you said there was no previous version on arm so users could've reported some issues, i agree that sometimes you have to ignore the rules to really fix stable, but was this such case for sure? I've done straight to stable keywording _many_ times. The rationale is that with no previous version stable for a particular architecture, there really are no users who could see _regressions_, hence waiting the nominal thirty days is meaningless in this case. jer another note: I was told a while back (I might still have it in irc logs), that 30 days is NOT a rule. It's common sense, but in the end the maintainer decides when to request stabilization, no one else. Blame people if they break something, not if they ignore soft policies.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
On 03/10/2013 02:11 PM, hasufell wrote: On 03/10/2013 07:04 PM, Jeroen Roovers wrote: On Sun, 3 Mar 2013 12:44:18 +0100 Tomáš Chvátal tomas.chva...@gmail.com wrote: If I remember correctly the damn rule is to put it for 30 days into testing, and as you said there was no previous version on arm so users could've reported some issues, i agree that sometimes you have to ignore the rules to really fix stable, but was this such case for sure? I've done straight to stable keywording _many_ times. The rationale is that with no previous version stable for a particular architecture, there really are no users who could see _regressions_, hence waiting the nominal thirty days is meaningless in this case. jer another note: I was told a while back (I might still have it in irc logs), that 30 days is NOT a rule. It's common sense, but in the end the maintainer decides when to request stabilization, no one else. Blame people if they break something, not if they ignore soft policies. What's broken is the expectation that the package was tested by more than one person. The soft policy is here: http://devmanual.gentoo.org/keywording/index.html#moving-from-~arch-to-arch And you're right, ~30 days is simply a suggestion. But the rule is The package has spent a reasonable amount of time in ~arch first. A further non-suggestion is The package must be widely tested. If a package is marked stable, I expect it to have seen some testing, and not just on the maintainers personal machine. I don't rely 100% on the stable designation, but it does affect the amount of testing that I personally will do. Please help me do my job by not perverting the meaning of stable.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
hasufell posted on Sun, 10 Mar 2013 19:11:52 +0100 as excerpted: I was told a while back (I might still have it in irc logs), that 30 days is NOT a rule. It's common sense, but in the end the maintainer decides when to request stabilization, no one else. I can confirm the 30-day-guideline policy was just that, a maintainer- discretion guideline, back in 2005/2006 or so when I first became aware of the concept via discussion. It was explained as maintainer knows their packages best, with the caveat that arch-teams also knew their archs best and could choose not to stabilize right away if they decided the request wasn't appropriate for their arch. I've seen no council, etc. decision changing that, over the years. Sometime a bit thereafter, various understaffed archs began to yield stabilizing authority to non-arch-team maintainers on a package-by- package basis, generally with at least the requirement that said maintainer actually had access to and had tested on that arch. AFAIK, before that maintainers weren't to stabilize at all on archs they weren't team members of, but they could still do so if they were a member of the arch-team, provided of course that they were following arch-team policy in the process. Meanwhile, jer's explanation, that on an arch where the package was not previously stable, there could be no stable users of the app to see regressions, so straight to stable makes a bit more sense, makes perfect sense to me. =:^) If I'm arguably too verbose, vapier's arguably not verbose enough. Had he just said something like either of these instead of simply punting with his replies... I guess it would have stopped there. -- 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: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
Am Montag, 4. März 2013, 03:19:17 schrieb Peter Stuge: Again, I guess you have to make Mike go away now. I never said that so please just stop it. You threatened to preempt me if I wanted to become a developer and found his practise OK - meaning that the behavior is unacceptable. If you are to be the least consistent you really need to also threaten to remove him. (It would be pretty ridiculously hipocratic and of course harmful for project evolution if the rules apply only to aspiring devs.) But I'd obviously prefer if you didn't do that to him. Seriously. While I'm all for sticking to the rules, I'm also sometimes glad that Gentoo is not as bad as proverbial German bureaucracy. The fact is, people who have been around for a long time, do a lot of important work and are trusted by the dev community may be able to bend the rules *for good reason*. [I personally would prefer if that would occur less frequently though.] This discussion is about whether it was really necessary (the for good reason part) or could have been done in other ways. Starting as a developer or aspiring to become one with that attitude is not acceptable. No discussion of that needed. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
Andreas K. Huettel wrote: Starting as a developer or aspiring to become one with that attitude is not acceptable. That doesn't make sense to me. If the reason is good, surely it does not matter who is doing the breaking? //Peter pgpvkacjjiVYz.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
On Mon, Mar 4, 2013 at 5:58 AM, Peter Stuge pe...@stuge.se wrote: Andreas K. Huettel wrote: Starting as a developer or aspiring to become one with that attitude is not acceptable. That doesn't make sense to me. If the reason is good, surely it does not matter who is doing the breaking? Well there is an implication that new developers are not experienced and are more prone to making choices with faulty reasoning. This is obviously not true of all new developers, but likely remains a good heuristic. -A //Peter
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
On Mar 3, 2013 2:42 AM, Peter Stuge pe...@stuge.se wrote: Markos Chandras wrote: it just feels strange I hear they call it getting stuff done.. //Peter good thing you are not a dev then. Thanks for the heads up in case you ever want to become one
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
If I remember correctly the damn rule is to put it for 30 days into testing, and as you said there was no previous version on arm so users could've reported some issues, i agree that sometimes you have to ignore the rules to really fix stable, but was this such case for sure? Dne 3.3.2013 3:43 Mike Frysinger vap...@gentoo.org napsal(a): On Saturday 02 March 2013 21:01:39 Markos Chandras wrote: On Mar 3, 2013 1:55 AM, Mike Frysinger vap...@gentoo.org wrote: complain to me when all these arm systems that totally had confuse already installed go down in fire. it literally makes 0 difference here. Why would they have it installed (in stable) if it had no keywords? and if it is such an important package why it didn't have testing keywords in the first place? I did't say it broke something, it just feels strange and this is why I asked sounds like there's no further clarification necessary -mike
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
Markos Chandras wrote: it just feels strange I hear they call it getting stuff done.. good thing you are not a dev then. Thanks for the heads up in case you ever want to become one I explain to you what happened and you, a recruiter, proceed to threaten me in case I want to become a developer. And people wonder if anything is wrong with Gentoo recruitment.. Back on topic: It seems that you must immediately retire Mike. (Or the rule..) //Peter
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
On 3 March 2013 12:01, Peter Stuge pe...@stuge.se wrote: Markos Chandras wrote: it just feels strange I hear they call it getting stuff done.. good thing you are not a dev then. Thanks for the heads up in case you ever want to become one I explain to you what happened getting stuff done is not an answer. I still don't understand why stable keywords had to be added directly. Do you understand why Mike did that or just playing smart here? Instead of you giving me cryptic and smart answers, you could have explained to me why it was necessary and job done. and you, a recruiter, proceed to threaten me in case I want to become a developer. And people wonder if anything is wrong with Gentoo recruitment.. If you can't play by the rules, either try to change them or go away or at least try to explain why you break them. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
Markos Chandras wrote: I explain to you what happened getting stuff done is not an answer. I still don't understand why stable keywords had to be added directly. Do you understand why Mike did that or just playing smart here? To me it's obvious that he did it because it made something easier for him. By breaking the Gentoo rule he got something done. Instead of you giving me cryptic and smart answers, you could have explained to me why it was necessary and job done. I have no idea what exactly became easier for him, and what it is may be none of our business. and you, a recruiter, proceed to threaten me in case I want to become a developer. And people wonder if anything is wrong with Gentoo recruitment.. If you can't play by the rules, either try to change them or go away or at least try to explain why you break them. Again, I guess you have to make Mike go away now. On rules: It's very easy to create bad rules while having the best intentions. The road to hell is paved with good intentions. It takes immense effort to change such rules, and an establishment which has grown fond of them. It sadly seems much easier to maintain a whole separate portage tree than to fix broken rules. :\ That said, I don't know what route I'll choose if I ever have to. //Peter
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
On Sun, Mar 3, 2013 at 7:38 AM, Peter Stuge pe...@stuge.se wrote: To me it's obvious that he did it because it made something easier for him. By breaking the Gentoo rule he got something done. Rules exist for a reason. If we're bending them because we're accomplishing the goal of the rules in a better way that makes sense. If we're just breaking them because following them is inconvenient then we're causing harm. The purpose of the 30-day rule is so that stable is, well, stable. Stable doesn't mean I think this should work. Stable means that it has been tested and found to work - a time delay is almost essential to the definition of stability. There is room for an exception if there is some serious problem in stable and the risk of causing harm is low compared to the pain already being felt. Security bugs usually involve breaking the 30-day rule, for example. In these cases the spirit of the rule is contrary to the letter of the rule, and we rightly violate the letter as a result. There is no harm in pointing out that a rule was broken. If there is a good reason it will be produced and everybody will nod, and if not, well, then hopefully there will be an apology and we'll just move on. Neither blacklisting nor banishment are the right first response to a minor offense, but devs have been booted for consistently violating rules like the 30 day rule, and I would expect mentors and recruiters to ensure that new recruits understand and intend to follow this rule. Anybody who runs a stable system is better off for it. Countless threads on -dev (mail or irc) amount to I'd like to violate this rule for a good reason. There is some debate, and we either do it or not. Rules aren't intended to prevent progress, but quality is important and if a rule is standing in your way there might be some side of the problem that you're not seeing. It never hurts to ask before breaking a rule. Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
On 3 March 2013 12:38, Peter Stuge pe...@stuge.se wrote: Markos Chandras wrote: I explain to you what happened getting stuff done is not an answer. I still don't understand why stable keywords had to be added directly. Do you understand why Mike did that or just playing smart here? To me it's obvious that he did it because it made something easier for him. By breaking the Gentoo rule he got something done. I asked why he did it, and you keep telling me because he had to. When you are in place to give me a more detailed answer please do so otherwise I am asking you to stop making noise on the list. Instead of you giving me cryptic and smart answers, you could have explained to me why it was necessary and job done. I have no idea what exactly became easier for him, and what it is may be none of our business. Maybe it is not your business, but I am reviewing commits from time to time because: a) I often see useful tricks in ebuild writing so it is a good learning procedure and b) because some people may did a bad commit so I would like to be there and point them at it In this case, I would like to know the reasoning behind that commit. I am not the Gentoo police, just trying to understand the commits that don't make sense to me. It this *that* hard for you to understand it? Again, I guess you have to make Mike go away now. I never said that so please just stop it. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
Markos Chandras wrote: getting stuff done is not an answer. it made something easier for him I asked why he did it, and you keep telling me because he had to. I'm guessing that it didn't have much to do with Gentoo. Maybe he'll fill in. I am reviewing commits from time to time because: b) people may did a bad commit so I would like to be there and point them I am not the Gentoo police That looks really confusing. I think you are contradicting yourself. But I guess never mind. Again, I guess you have to make Mike go away now. I never said that so please just stop it. You threatened to preempt me if I wanted to become a developer and found his practise OK - meaning that the behavior is unacceptable. If you are to be the least consistent you really need to also threaten to remove him. (It would be pretty ridiculously hipocratic and of course harmful for project evolution if the rules apply only to aspiring devs.) But I'd obviously prefer if you didn't do that to him. //Peter
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
On Friday 01 March 2013 07:45:28 Markos Chandras wrote: On 1 March 2013 08:16, Mike Frysinger (vapier) vap...@gentoo.org wrote: vapier 13/03/01 08:16:02 Modified: confuse-2.7.ebuild ChangeLog Log: Add arm lovin. --- confuse-2.7.ebuild 30 Oct 2012 11:18:49 - 1.12 +++ confuse-2.7.ebuild 1 Mar 2013 08:16:02 - 1.13 -KEYWORDS=alpha amd64 hppa ia64 ~mips ppc ppc64 sparc x86 ~sparc-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos ~x86-solaris +KEYWORDS=alpha amd64 arm hppa ia64 ~mips ppc ppc64 sparc x86 ~sparc-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos ~x86-solaris straight to stable? Not even keeping it to testing just for a week or so? looks that way -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
On Mar 3, 2013 1:43 AM, Mike Frysinger vap...@gentoo.org wrote: On Friday 01 March 2013 07:45:28 Markos Chandras wrote: On 1 March 2013 08:16, Mike Frysinger (vapier) vap...@gentoo.org wrote: vapier 13/03/01 08:16:02 Modified: confuse-2.7.ebuild ChangeLog Log: Add arm lovin. --- confuse-2.7.ebuild 30 Oct 2012 11:18:49 - 1.12 +++ confuse-2.7.ebuild 1 Mar 2013 08:16:02 - 1.13 -KEYWORDS=alpha amd64 hppa ia64 ~mips ppc ppc64 sparc x86 ~sparc-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos ~x86-solaris +KEYWORDS=alpha amd64 arm hppa ia64 ~mips ppc ppc64 sparc x86 ~sparc-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos ~x86-solaris straight to stable? Not even keeping it to testing just for a week or so? looks that way -mike Ok good to know you break the rules on purpose
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
On Saturday 02 March 2013 20:50:17 Markos Chandras wrote: On Mar 3, 2013 1:43 AM, Mike Frysinger vap...@gentoo.org wrote: On Friday 01 March 2013 07:45:28 Markos Chandras wrote: On 1 March 2013 08:16, Mike Frysinger wrote: vapier 13/03/01 08:16:02 Modified: confuse-2.7.ebuild ChangeLog Log: Add arm lovin. --- confuse-2.7.ebuild 30 Oct 2012 11:18:49 - 1.12 +++ confuse-2.7.ebuild 1 Mar 2013 08:16:02 - 1.13 -KEYWORDS=alpha amd64 hppa ia64 ~mips ppc ppc64 sparc x86 ~sparc-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos ~x86-solaris +KEYWORDS=alpha amd64 arm hppa ia64 ~mips ppc ppc64 sparc x86 ~sparc-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos ~x86-solaris straight to stable? Not even keeping it to testing just for a week or so? looks that way Ok good to know you break the rules on purpose complain to me when all these arm systems that totally had confuse already installed go down in fire. it literally makes 0 difference here. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
On Mar 3, 2013 1:55 AM, Mike Frysinger vap...@gentoo.org wrote: On Saturday 02 March 2013 20:50:17 Markos Chandras wrote: On Mar 3, 2013 1:43 AM, Mike Frysinger vap...@gentoo.org wrote: On Friday 01 March 2013 07:45:28 Markos Chandras wrote: On 1 March 2013 08:16, Mike Frysinger wrote: vapier 13/03/01 08:16:02 Modified: confuse-2.7.ebuild ChangeLog Log: Add arm lovin. --- confuse-2.7.ebuild 30 Oct 2012 11:18:49 - 1.12 +++ confuse-2.7.ebuild 1 Mar 2013 08:16:02 - 1.13 -KEYWORDS=alpha amd64 hppa ia64 ~mips ppc ppc64 sparc x86 ~sparc-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos ~x86-solaris +KEYWORDS=alpha amd64 arm hppa ia64 ~mips ppc ppc64 sparc x86 ~sparc-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos ~x86-solaris straight to stable? Not even keeping it to testing just for a week or so? looks that way Ok good to know you break the rules on purpose complain to me when all these arm systems that totally had confuse already installed go down in fire. it literally makes 0 difference here. -mike Why would they have it installed (in stable) if it had no keywords? and if it is such an important package why it didn't have testing keywords in the first place? I did't say it broke something, it just feels strange and this is why I asked
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
Markos Chandras wrote: it just feels strange I hear they call it getting stuff done.. //Peter
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
On Saturday 02 March 2013 21:01:39 Markos Chandras wrote: On Mar 3, 2013 1:55 AM, Mike Frysinger vap...@gentoo.org wrote: complain to me when all these arm systems that totally had confuse already installed go down in fire. it literally makes 0 difference here. Why would they have it installed (in stable) if it had no keywords? and if it is such an important package why it didn't have testing keywords in the first place? I did't say it broke something, it just feels strange and this is why I asked sounds like there's no further clarification necessary -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
On 1 March 2013 08:16, Mike Frysinger (vapier) vap...@gentoo.org wrote: vapier 13/03/01 08:16:02 Modified: confuse-2.7.ebuild ChangeLog Log: Add arm lovin. (Portage version: 2.2.0_alpha163/cvs/Linux x86_64, signed Manifest commit with key FB7C4156) Revision ChangesPath 1.13 dev-libs/confuse/confuse-2.7.ebuild file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-libs/confuse/confuse-2.7.ebuild?rev=1.13view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-libs/confuse/confuse-2.7.ebuild?rev=1.13content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-libs/confuse/confuse-2.7.ebuild?r1=1.12r2=1.13 Index: confuse-2.7.ebuild === RCS file: /var/cvsroot/gentoo-x86/dev-libs/confuse/confuse-2.7.ebuild,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- confuse-2.7.ebuild 30 Oct 2012 11:18:49 - 1.12 +++ confuse-2.7.ebuild 1 Mar 2013 08:16:02 - 1.13 @@ -1,6 +1,6 @@ -# Copyright 1999-2012 Gentoo Foundation +# Copyright 1999-2013 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 -# $Header: /var/cvsroot/gentoo-x86/dev-libs/confuse/confuse-2.7.ebuild,v 1.12 2012/10/30 11:18:49 blueness Exp $ +# $Header: /var/cvsroot/gentoo-x86/dev-libs/confuse/confuse-2.7.ebuild,v 1.13 2013/03/01 08:16:02 vapier Exp $ EAPI=3 @@ -10,7 +10,7 @@ LICENSE=ISC SLOT=0 -KEYWORDS=alpha amd64 hppa ia64 ~mips ppc ppc64 sparc x86 ~sparc-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos ~x86-solaris +KEYWORDS=alpha amd64 arm hppa ia64 ~mips ppc ppc64 sparc x86 ~sparc-fbsd ~x86-fbsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos ~x86-solaris IUSE=nls static-libs DEPEND=sys-devel/flex straight to stable? Not even keeping it to testing just for a week or so? -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
