Donnie Berkholz wrote:
On 13:23 Thu 31 Jul , Stuart Longland wrote:
An alternative however, I'd like to propose is the addition of a 'lm2e'
local USE flag to the affected ebuilds
Stuart,
I'm glad to hear you've made progress on this and gotten things working!
As soon as you get
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It seems,
Slightly like an abuse of the RESTRICT variable. I had thought that
RESTRICT was generally for when a normal ebuild needed a feature turning
off (such as mirroring, strict checking and hopefully one day ccache).
5:) Overloading it
2008-08-02 04:02:48 Zac Medico napisał(a):
Hi everyone,
It might good to add support for a new RESTRICT=live value in
ebuilds. By specifying this value, an ebuild would be able to
indicate that it uses src_unpack() to download sources from some
type of live repository such as cvs, darcs,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arfrever Frehtes Taifersar Arahesis wrote:
2008-08-02 04:02:48 Zac Medico napisał(a):
The names of other RESTRICT values are related to features which are
restricted. The new proposed value is intended for live ebuilds so its
name should be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Auty wrote:
It seems,
Slightly like an abuse of the RESTRICT variable. I had thought that
RESTRICT was generally for when a normal ebuild needed a feature turning
off (such as mirroring, strict checking and hopefully one day ccache).
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zac Medico wrote:
| Honestly I don't care what the existing scheme is.
Fair enough, I don't maintain the code or have to deal with the
complaints. It seems a waste to abandon an existing scheme though.
Particularly since RESTRICT is an odd name
On Friday 01 August 2008, Chrissy Fullam wrote:
Debian did exactly the same a couple of months
ago prior to them moving out to OFTC
(http://www.debian.org/News/2006/20060604)
This addresses a question I raised a few days back regarding whether
we were concerned that Gentoo moving to any
On Sat, Aug 2, 2008 at 12:26 PM, Zac Medico [EMAIL PROTECTED] wrote:
Mike Auty wrote:
If there's need for a new class of ebuild information (such as a new
way of categorizing ebuilds by feature), perhaps we should add an ebuild
features variable specifically for the purpose?
That
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Santiago M. Mola wrote:
On Sat, Aug 2, 2008 at 12:26 PM, Zac Medico [EMAIL PROTECTED] wrote:
Mike Auty wrote:
If there's need for a new class of ebuild information (such as a new
way of categorizing ebuilds by feature), perhaps we should add
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Auty wrote:
Zac Medico wrote:
| Honestly I don't care what the existing scheme is.
Fair enough, I don't maintain the code or have to deal with the
complaints. It seems a waste to abandon an existing scheme though.
The scheme is pretty
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arfrever Frehtes Taifersar Arahesis wrote:
2008-08-02 04:02:48 Zac Medico napisał(a):
The names of other RESTRICT values are related to features which are
restricted. The new proposed value is intended for live ebuilds so its
name should be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zac Medico schrieb:
I chose live because I think it's easy for people to associate it
with live ebuilds, which I believe is a common term used to refer
to ebuild that download live sources in src_unpack. What's in a name
though? I'll gladly use
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
René 'Necoro' Neumann wrote:
Zac Medico schrieb:
I chose live because I think it's easy for people to associate it
with live ebuilds, which I believe is a common term used to refer
to ebuild that download live sources in src_unpack. What's in a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zac Medico schrieb:
Well, RESTRICT has long since evolved into a rather generic set of
boolean flags and it's quite useful as such. I don't see any need
for artificial limitations on what types of flags go there.
For you it is just one variable
Zac Medico wrote:
Arfrever Frehtes Taifersar Arahesis wrote:
2008-08-02 04:02:48 Zac Medico napisaB(a):
The names of other RESTRICT values are related to features which are
restricted. The new proposed value is intended for live ebuilds so its
name should be negation of this feature. I think
On 16:43 Sat 02 Aug , Stuart Longland wrote:
Donnie Berkholz wrote:
On 13:23 Thu 31 Jul , Stuart Longland wrote:
An alternative however, I'd like to propose is the addition of a 'lm2e'
local USE flag to the affected ebuilds
Stuart,
I'm glad to hear you've made progress on
On Sun, Aug 3, 2008 at 4:36 AM, Zac Medico [EMAIL PROTECTED] wrote:
Arfrever Frehtes Taifersar Arahesis wrote:
2008-08-02 04:02:48 Zac Medico napisał(a):
The names of other RESTRICT values are related to features which are
restricted. The new proposed value is intended for live ebuilds so its
On Fri, Aug 1, 2008 at 7:02 PM, Zac Medico [EMAIL PROTECTED] wrote:
This new RESTRICT=live value would be useful in at least a couple of
ways. One is that it could be used to implement a @live-rebuild
package set that's based on RESTRICT instead of INHERITED [1]. It
could also be used to
On 2008/08/01, Zac Medico [EMAIL PROTECTED] wrote:
It might good to add support for a new RESTRICT=live value in
ebuilds.
Since some people have a problem with this flag being put there, what
about IUSE=live-rebuild as an alternative? It's use.desc would be
something like add this package to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
René 'Necoro' Neumann wrote:
| Zac Medico schrieb:
| Well, RESTRICT has long since evolved into a rather generic set of
| boolean flags and it's quite useful as such. I don't see any need
| for artificial limitations on what types of flags go there.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas de Grenier de Latour wrote:
On 2008/08/01, Zac Medico [EMAIL PROTECTED] wrote:
It might good to add support for a new RESTRICT=live value in
ebuilds.
Since some people have a problem with this flag being put there, what
about
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Avuton Olrich wrote:
On Fri, Aug 1, 2008 at 7:02 PM, Zac Medico [EMAIL PROTECTED] wrote:
For some of us in the peanut gallery it'd also be nice to document the
pitfalls of grepping inherited to determine if it's a live ebuild
(update-live-ebuilds
On 2008/08/02, Zac Medico [EMAIL PROTECTED] wrote:
USE flags are something that can be enable or disabled
Here, what the flag would enable/disable is belonging of live packages
to the @live-rebuild set. Compared to the RESTRICT solution, user
gains an easy per-package control of this set
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas de Grenier de Latour wrote:
On 2008/08/02, Zac Medico [EMAIL PROTECTED] wrote:
USE flags are something that can be enable or disabled
Here, what the flag would enable/disable is belonging of live packages
to the @live-rebuild set.
Hi all,
There are lots of portage packages that hasn't got jobserver, (i.e. gcc,
firefox...)
and can be compiled only at one thread/core.
This is waste of time and resources on dualcore/quadcore cpus.
How about mark packages with number of threads it can be compiled ?
(ie.
T0 - no limits of
On 2008-08-02 12:14, litlle girl uttered these thoughts:
Iproved emerge command will be able to compile two or more packages
(each 1 thread marked) at the same time (if this packages don't depend on
each other).
Then wait until compilation ends, and start multithread marked packages
thanks,
this is what i was looking for...
:D
regs
LLG
I will be out of the office starting 07/31/2008 and will not return until
08/18/2008.
I will be out of the office from 8/4/07, returning 8/20/07.
29 matches
Mail list logo
