Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread George Prowse
Ciaran McCreesh wrote: On Thu, 14 May 2009 20:06:51 +0200 Patrick Lauer wrote: "You need to know the EAPI to parse the ebuild to find the EAPI" Obviously that's not true, because somehow we manage at the moment. And if one does a small restriction (which doesn't restrict current behaviour becau

[gentoo-dev] libusb-1/libusb-compat landing - testing and DEPEND changes needed

2009-05-14 Thread Robin H. Johnson
libusb-1 is in the tree now. This means that you get to go and test all your apps that use it. There's a list further down of all packages and all ebuilds. Every one of these needs to be tested, and amended in one of two ways: - Does work with libusb-compat: 1. Change your [R]DEPEND to virtual

Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread Patrick Lauer
On Thursday 14 May 2009 23:53:37 Ciaran McCreesh wrote: > On Thu, 14 May 2009 16:49:09 -0500 > > William Hubbs wrote: > > The second solution seems to be the better one because it does not go > > against standards. For example, we see extentions like .c, .py and > > .pl, instead of .c-43, .py-25

Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread Ciaran McCreesh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 14 May 2009 16:49:09 -0500 William Hubbs wrote: > The second solution seems to be the better one because it does not go > against standards. For example, we see extentions like .c, .py and > .pl, instead of .c-43, .py-25 and .pl-58. There ar

Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread William Hubbs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I realize that I'm asking this very late in the discussion, so please bear with me if it has been hashed before. On Thu, May 14, 2009 at 11:16:23PM +0200, Peter Alfredsen wrote: > We need a mechanism to be able to use newer bash-features in ebuil

Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread Peter Alfredsen
On Thu, 14 May 2009 22:03:22 +0200 Ben de Groot wrote: > I concur that speaking for myself, I don't understand the issue. And > it looks like many others don't either. So if anyone wants to promote > this GLEP, their job is clear: make people understand what the issue > is here, and convince them

Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread Ben de Groot
Patrick Lauer wrote: > For quite some time (over a year, actually) we've been discussing the > mysterious and often misunderstood GLEP55. > [http://www.gentoo.org/proj/en/glep/glep-0055.html] > > The proposed solution to a problem that is never refined, This, in my opinion, is the crux of the m

Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread Ciaran McCreesh
On Thu, 14 May 2009 21:24:14 +0200 Patrick Lauer wrote: > > "so with glep55 caching it is actually slower!" > > > > There's no possible way that can make sense. Whatever he's claiming > > by that is obviously nonsense. > > Ah. I was not precise enough. > > Let me rephrase it in less ambiguous te

Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread Ciaran McCreesh
On Thu, 14 May 2009 14:15:28 -0500 Jeremy Olexa wrote: > On Thu, May 14, 2009 at 2:06 PM, David Leverton > wrote: > > yourself, "shell-like".   "printf -v EAPI 1" is perfectly valid > > shell (at least if we decide to allow bash 3.1 features), and has > > the same effect > > To stir things up: >

Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread Patrick Lauer
On Thursday 14 May 2009 21:20:18 Ciaran McCreesh wrote: > On Thu, 14 May 2009 13:17:24 -0600 > > RB wrote: > > On Thu, May 14, 2009 at 13:11, Ciaran McCreesh > > > > wrote: > > > Please explain why you claimed GLEP 55 makes things slower. Until > > > you answer that, it's hard to take you for any

Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread Ciaran McCreesh
On Thu, 14 May 2009 13:17:24 -0600 RB wrote: > On Thu, May 14, 2009 at 13:11, Ciaran McCreesh > wrote: > > Please explain why you claimed GLEP 55 makes things slower. Until > > you answer that, it's hard to take you for anything other than a > > troll. > > Hell, I'll explain. Read paragraph 8 a

Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread Ciaran McCreesh
On Thu, 14 May 2009 21:09:58 +0200 Tomáš Chvátal wrote: > Dne čtvrtek 14 Květen 2009 20:39:07 Ciaran McCreesh napsal(a): > > Where on earth are you getting the idea that GLEP 55 makes things > > slower? The only difference to the code with GLEP 55 is in checking > > file extensions against a sligh

Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread RB
On Thu, May 14, 2009 at 13:11, Ciaran McCreesh wrote: > Please explain why you claimed GLEP 55 makes things slower. Until you > answer that, it's hard to take you for anything other than a troll. Hell, I'll explain. Read paragraph 8 again. Slowly. Read it a second time, since you obviously did

Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread Robert Bridge
Patrick Lauer wrote: On Thursday 14 May 2009 20:39:07 Ciaran McCreesh wrote: On Thu, 14 May 2009 20:06:51 +0200 Patrick Lauer wrote: Let EAPI be defined as (the part behind the = of) the first line of the ebuild starting with EAPI= Uh, so horribly utterly and obviously wrong. inherit fo

Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread Jeremy Olexa
On Thu, May 14, 2009 at 2:06 PM, David Leverton wrote: > yourself, "shell-like".   "printf -v EAPI 1" is perfectly valid shell (at > least if we decide to allow bash 3.1 features), and has the same effect To stir things up: Who decides this? There are more and more bash-3.1 features in the tree a

Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread Ciaran McCreesh
On Thu, 14 May 2009 21:05:52 +0200 Patrick Lauer wrote: > > Where on earth are you getting the idea that GLEP 55 makes things > > slower? The only difference to the code with GLEP 55 is in checking > > file extensions against a slightly larger set of strings, which is > > nowhere near a measurable

Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread Tomáš Chvátal
Dne čtvrtek 14 Květen 2009 20:39:07 Ciaran McCreesh napsal(a): > Where on earth are you getting the idea that GLEP 55 makes things > slower? The only difference to the code with GLEP 55 is in checking > file extensions against a slightly larger set of strings, which is > nowhere near a measurable i

Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread David Leverton
On Thursday 14 May 2009 19:06:51 Patrick Lauer wrote: > For quite some time (over a year, actually) we've been discussing the > mysterious and often misunderstood GLEP55. > [http://www.gentoo.org/proj/en/glep/glep-0055.html] We agree on the latter adjective, if nothing else. > The proposed soluti

Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread Patrick Lauer
On Thursday 14 May 2009 20:39:07 Ciaran McCreesh wrote: > On Thu, 14 May 2009 20:06:51 +0200 > > Patrick Lauer wrote: > > "You need to know the EAPI to parse the ebuild to find the EAPI" > > Obviously that's not true, because somehow we manage at the moment. > > And if one does a small restriction

Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted

2009-05-14 Thread Thomas Sachau
Roy Bamford schrieb: > We could use user contributed ebuilds attached to bugs as a way to > bring Sunrise to the contributors attention just by posting a comment > to the bug. If the contributor follows up, we get another user > maintained ebuild in Sunrise, which is good, as the current develop

Re: [gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread Ciaran McCreesh
On Thu, 14 May 2009 20:06:51 +0200 Patrick Lauer wrote: > "You need to know the EAPI to parse the ebuild to find the EAPI" > Obviously that's not true, because somehow we manage at the moment. > And if one does a small restriction (which doesn't restrict current > behaviour because all in-tree ebu

Re: [gentoo-dev] Re: Files owned by multiple slots

2009-05-14 Thread Ciaran McCreesh
On Thu, 14 May 2009 18:34:29 + (UTC) Sven wrote: > Duncan <1i5t5.duncan cox.net> writes: > > FWIW, that'd not be a portage issue per se, but an EAPI issue, > > since it > > I see, very interesting! Sounds like a lengthy process, but never > mind. Do you know where EAPI changes are discussed?

[gentoo-dev] Re: Files owned by multiple slots

2009-05-14 Thread Sven
Duncan <1i5t5.duncan cox.net> writes: > FWIW, that'd not be a portage issue per se, but an EAPI issue, since it I see, very interesting! Sounds like a lengthy process, but never mind. Do you know where EAPI changes are discussed? (Google and the Bugtracker didn't yield a useful reply.) Cheers, -

Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted

2009-05-14 Thread Roy Bamford
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2009.05.14 01:32, Mart Raudsepp wrote: > Hello, > [snip] > Project maintainer-wanted > = > > Abstract: > There are currently quite some package requests (over 3000) > languishing > on bugzilla waiting for a developer or te

[gentoo-dev] The fallacies of GLEP55

2009-05-14 Thread Patrick Lauer
For quite some time (over a year, actually) we've been discussing the mysterious and often misunderstood GLEP55. [http://www.gentoo.org/proj/en/glep/glep-0055.html] The proposed solution to a problem that is never refined, in short, is to add the EAPI into the ebuild filename "to make things easi

Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted

2009-05-14 Thread Thomas Sachau
Mart Raudsepp schrieb: >> If people are a) too lazy to contribute to sunrise, b) don't >> know about sunrise, or c) don't know enough about ebuilds to contribute >> to sunrise, then we need to fix[1] that. > > Sure, the sunrise project can do all of that. That doesn't make the > packages availab

Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted

2009-05-14 Thread Richard Freeman
Mart Raudsepp wrote: Liking and using the package yourself shouldn't be a prerequisite for a package getting to be in-tree by the maintainer-wanted team. How about actually maintaining the package? For example, user contributes ebuild for foo-1.0. I don't use it or like it, but I go ahead

Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted

2009-05-14 Thread Richard Freeman
AllenJB wrote: All that's going to happen is Gentoo will have many many buggy and out of date packages in the MAIN TREE. Exactly where they shouldn't be. You claim quality won't be sacrificed, but I simply can't see this without any attempt to solve the manpower issues first. Isn't the purp

Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted

2009-05-14 Thread Mart Raudsepp
On N, 2009-05-14 at 14:02 +0300, Markos Chandras wrote: > On Thursday 14 May 2009 03:32:12 Mart Raudsepp wrote: > > Hello, > > > > I have had this project in my mind for a while, so it's about time to > >[..] > I think there is no need for this project. Developers can always browse > bugzilla and

Re: [gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted

2009-05-14 Thread Nirbheek Chauhan
To potential responders to this message: Nothing to see here, please move along. Everytime you reply to this message, a kitten is deleted. 2009/5/14 Alexander Færøy : > On Thu, May 14, 2009 at 07:54:35AM +0200, Patrick Lauer wrote: >> Yes, one did. Some people just need a good excuse to leave :)

Re: [gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted

2009-05-14 Thread Alexander Færøy
On Thu, May 14, 2009 at 07:54:35AM +0200, Patrick Lauer wrote: > Yes, one did. Some people just need a good excuse to leave :) You lost the best laptop developer Gentoo had ever had.. -- Alexander Færøy http://dev.exherbo.org/~ahf/ pgpscOKrRfN37.pgp Description: PGP signature

Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted

2009-05-14 Thread Markos Chandras
On Thursday 14 May 2009 03:32:12 Mart Raudsepp wrote: > Hello, > > I have had this project in my mind for a while, so it's about time to >[..] I think there is no need for this project. Developers can always browse bugzilla and pick every 'maintainer-wanted' ebuild they like. At least this is wh

Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted

2009-05-14 Thread Mart Raudsepp
On Wed, 2009-05-13 at 20:47 -0500, Jeremy Olexa wrote: > Mart Raudsepp wrote: > > Hello, Hey, > > I have had this project in my mind for a while, so it's about time to > > get it out there, as to see if feedback finds it a good one - and if > > that is so, if there are people who want to make it

[gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted

2009-05-14 Thread Christian Faulhammer
Hi, Jeremy Olexa : > I don't see any reason to create a team that duplicates the sunrise > work. More power to Sunrise, yes. Sunrise is a great project, although I don't dedicate too much time for it nowadays. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/l

[gentoo-dev] Re: Passing arguments to eqmake3

2009-05-14 Thread Christian Faulhammer
Hi, Nikos Chantziaras : > > Btw: Is there a typo in the eclass? Shouldn't it be "Project .pro > > file "PREFIX=/usr" does not exist" instead of "Project .pro file > > "PREFIX=/usr" does not exists" > > I just checked qt3.eclass and indeed its a typo in there. Which is now gone. V-Li -- Chris

[gentoo-dev] Re: Passing arguments to eqmake3

2009-05-14 Thread Christian Faulhammer
Hi, Nikos Chantziaras : > Daniel Pielmeier wrote: > > Also this question is not appropriate for this list. The > > gentoo-devhelp mailing-list or #gentoo-dev-help on IRC are better > > places for this kind of questions. > > My posts to gmane.linux.gentoo.devhelp don't seem to get through. > Does

[gentoo-dev] Re: Passing arguments to eqmake3

2009-05-14 Thread Duncan
Nikos Chantziaras posted gugfo5$i9...@ger.gmane.org, excerpted below, on Thu, 14 May 2009 10:03:43 +0300: > I worked around it by subscribing manually to that list (using the > "-nomail" list option). After that, postings from GMane get through. Thanks. (Further reply/explanation offlist.) -

[gentoo-dev] Re: Passing arguments to eqmake3

2009-05-14 Thread Nikos Chantziaras
Duncan wrote: Nikos Chantziaras posted gufm71$un...@ger.gmane.org, excerpted below, on Thu, 14 May 2009 02:47:55 +0300: My posts to gmane.linux.gentoo.devhelp don't seem to get through. Does someone know if something is wrong with the list's subscription on GMane? All other GMane Gentoo lis