On Tue, 2009-05-12 at 21:45 +0100, Sérgio Almeida wrote:
How about having the profile switch automatic whenever
you call uselect something getting the current profile settings from
current dir's .uselect folder?
Yeah, this indeed could work!
But there is one restriction:
This .uselect folder
Patrick Lauer wrote:
Then there's package management. (Your favourite topic, I guess, because you
want to keep complexifying it until one needs a PhD to write an ebuild
[which,
in a way, would be quite ironic])
At least for me new EAPIs have been / are making ebuild writing easier.
Le mardi 12 mai 2009 à 22:55 +0200, Sven Schwyn a écrit :
Gilles wrote:
so this wrapper could be installed in a separate eselect sort of
package ?
How exactly can this be done? If a gem creates five executables, would
this mean that this gem comes in six ebuilds?
well given the next
On Tue, May 12, 2009 at 08:35:41AM +0200, Patrick Lauer wrote:
On Tuesday 12 May 2009 00:31:36 Ciaran McCreesh wrote:
On Mon, 11 May 2009 23:17:32 +0100
George Prowse george.pro...@gmail.com wrote:
An equilibrium seems to have been reached which currently works.
An equilibrium has
Gilles Dartiguelongue eva at gentoo.org writes:
so this wrapper could be installed in a separate eselect sort of
package ?
How exactly can this be done? If a gem creates five executables, would
this mean that this gem comes in six ebuilds?
well given the next answer, it sounds like
Sven sv...@delirium.ch posted loom.20090513t143352-...@post.gmane.org,
excerpted below, on Wed, 13 May 2009 14:34:20 +:
Yet meanwhile I'd love to get some feedback on my original proposition:
Is it feasable and acceptable to expand Portage by the possibility to
declare a file shared
Nikos Chantziaras wrote:
I have a package that uses qmake (from Qt 3) as its build system and
that installs into /usr/local by default (as any well packaged
software should do). This of course can be overridden at build time.
In this case, with:
qmake PREFIX=/usr projectfile.pro
In
Nikos Chantziaras schrieb am 13.05.2009 23:31:
I have a package that uses qmake (from Qt 3) as its build system and
that installs into /usr/local by default (as any well packaged software
should do). This of course can be overridden at build time. In this
case, with:
qmake PREFIX=/usr
I have a package that uses qmake (from Qt 3) as its build system and
that installs into /usr/local by default (as any well packaged software
should do). This of course can be overridden at build time. In this
case, with:
qmake PREFIX=/usr projectfile.pro
In order to install into /usr
Mounir Lamouri wrote:
Nikos Chantziaras wrote:
I have a package that uses qmake (from Qt 3) as its build system and
that installs into /usr/local by default (as any well packaged
software should do). This of course can be overridden at build time.
In this case, with:
qmake PREFIX=/usr
I have a package that uses qmake (from Qt 3) as its build system and
that installs into /usr/local by default (as any well packaged software
should do). This of course can be overridden at build time. In this
case, with:
qmake PREFIX=/usr projectfile.pro
In order to install into /usr (as
Daniel Pielmeier wrote:
Nikos Chantziaras schrieb am 13.05.2009 23:31:
I have a package that uses qmake (from Qt 3) as its build system and
that installs into /usr/local by default (as any well packaged software
should do). This of course can be overridden at build time. In this
case, with:
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
someone know if something is wrong with
Hello,
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 happen.
It is worded as a hypothetical project description for the purpose of
the text perhaps
Hi,
The project would be very beneficial if it gets live.
But from the very start its name should be unambigious,
I would suggest community-maintained as the name, including both the
developer community and user community.
And also, the project should advise the sunrise overlay for packages with
Mart Raudsepp wrote:
Hello,
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 happen.
It is worded as a hypothetical project description for the purpose
Mart Raudsepp wrote:
Hello,
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 happen.
snip
Hmm, I wonder what the point is when there is 400
Jeremy Olexa darks...@gentoo.org posted 4a0b783c.2000...@gentoo.org,
excerpted below, on Wed, 13 May 2009 20:47:40 -0500:
I don't see any reason to create a team that duplicates the sunrise
work. Keep in mind, I am against pretty much any overlay, I think work
should be kept in the main tree.
Nikos Chantziaras rea...@arcor.de 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
[Snip]
Maybe you just want Sunrise in the main tree instead of as a dedicated,
supervised overlay. There were people with VERY strong feelings against
Sunrise, to the point I believe at least one dev opposing it resigned
over it
Yes, one did. Some people just need a good excuse to leave :)
20 matches
Mail list logo
