On Thu, Sep 13, 2012 at 2:22 AM, Ulrich Mueller wrote:
>> On Thu, 13 Sep 2012, Mike Frysinger wrote:
>>> Maybe it's better to add a --{save,restore} option pair:
>>>
>>> addwrite --save /foo/bar
>>> # some commands writing to /foo/bar here
>>> addwrite --restore # restore last saved state
>>>
> On Thu, 13 Sep 2012, Mike Frysinger wrote:
>> Maybe it's better to add a --{save,restore} option pair:
>>
>> addwrite --save /foo/bar
>> # some commands writing to /foo/bar here
>> addwrite --restore # restore last saved state
>>
>> or --{push,pop} to allow for nested calls, but maybe th
On Thu, Sep 13, 2012 at 1:48 AM, Ulrich Mueller wrote:
>> On Thu, 13 Sep 2012, Brian Harring wrote:
>> Note there is a few vars we need to exempt; that list is currently
>> SANDBOX_* and FEATURES. FEATURES is fine to exempt from this rule.
>>
>> For SANDBOX_*, while that's a PM internal, that'
On Wed, Sep 12, 2012 at 4:36 PM, Brian Harring wrote:
> Currently, there is a minor amount of ebuild/eclass usage of things
> named __*; ~90% of it is 'import once' eclass code like the following:
>
> """
> if [[ ${___ECLASS_ONCE_LIBTOOL} != "recur -_+^+_- spank" ]] ; then
> ___ECLASS_ONCE_LIBTOOL=
> On Thu, 13 Sep 2012, Brian Harring wrote:
> Note there is a few vars we need to exempt; that list is currently
> SANDBOX_* and FEATURES. FEATURES is fine to exempt from this rule.
>
> For SANDBOX_*, while that's a PM internal, that's a bit of a grey
> zone; regardless, we can actually addr
Hi,
The council has approved [1] "Profile IUSE injection" [2] for inclusion
in EAPI 5, and in latest Portage we have experimental EAPI 5_pre2 [3]
which implements all of the approved features. So, now would be a good
time to start populating IUSE_IMPLICIT with whatever values may be
appropriate.
On 13 September 2012 04:36, Brian Harring wrote:
> Hola folks.
>
> Currently portage exposes a fair amount of it's internal
> implementation via vars/funcs into the ebulid env; this frankly makes
> it easier for ebuilds/eclasses to localize themselves to portage
> (rather than PMS), leading to bre
On 13 September 2012 09:43, Jeroen Roovers wrote:
> On Wed, 12 Sep 2012 20:53:20 +0200
> Pacho Ramos wrote:
>
>> > You can un-CC yourself. I don't see why security@ should be doing
>> > the legwork.
>>
>> It shouldn't be so hard to do, they can do it just when they CC
>> arches, instead of relayi
On Wed, 12 Sep 2012 20:53:20 +0200
Pacho Ramos wrote:
> > You can un-CC yourself. I don't see why security@ should be doing
> > the legwork.
>
> It shouldn't be so hard to do, they can do it just when they CC
> arches, instead of relaying some random team member to do it himself
> once a useless
On 09/12/2012 02:54 PM, Pacho Ramos wrote:
> El jue, 13-09-2012 a las 04:30 +1000, Michael Palimaka escribió:
>> On 2012-09-13 03:59, Pacho Ramos wrote:
>>> Hello
>>>
>>> Currently, package maintainers are CCed to security bugs when their are
>>> needed. The problem is that, once maintainers add a
Hola folks.
Currently portage exposes a fair amount of it's internal
implementation via vars/funcs into the ebulid env; this frankly makes
it easier for ebuilds/eclasses to localize themselves to portage
(rather than PMS), leading to breakage.
Thus a proposal for EAPI5 has been made, banning e
On Sun, 2012-09-09 at 22:09 -0400, Alexandre Rostovtsev wrote:
> Revised proposal with suggestions from Nirbheek. VALA_API_VERSION has
> been split into max and min to make it easier for packages to depend on
> a range of vala slots.
>
> # Copyright 1999-2012 Gentoo Foundation
> # Distributed unde
El mié, 12-09-2012 a las 14:42 -0400, Rich Freeman escribió:
> On Wed, Sep 12, 2012 at 2:29 PM, Jeroen Roovers wrote:
> >
> > So you would want to be re-CC'd when it is time to remove the vulnerable
> > versions, I guess.
>
> Isn't this done shortly after keywording is complete? I think the
> co
El jue, 13-09-2012 a las 04:30 +1000, Michael Palimaka escribió:
> On 2012-09-13 03:59, Pacho Ramos wrote:
> > Hello
> >
> > Currently, package maintainers are CCed to security bugs when their are
> > needed. The problem is that, once maintainers add a fixed version and
> > tell security team they
El mié, 12-09-2012 a las 20:29 +0200, Jeroen Roovers escribió:
> On Wed, 12 Sep 2012 19:59:01 +0200
> Pacho Ramos wrote:
>
> > Hello
> >
> > Currently, package maintainers are CCed to security bugs when their
> > are needed. The problem is that, once maintainers add a fixed version
> > and tell
On 9/12/2012 5:58 AM, Ian Stakenvicius wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/09/12 05:55 AM, Gregory M. Turner wrote:
Note that, effectively, we have this already, and it's called
"portage". But one could certainly make a case for modularizing it
better, since, in truth,
On Wed, Sep 12, 2012 at 2:29 PM, Jeroen Roovers wrote:
>
> So you would want to be re-CC'd when it is time to remove the vulnerable
> versions, I guess.
Isn't this done shortly after keywording is complete? I think the
concern is more about issuing GLSAs/etc, which apparently can happen
months o
On 2012-09-13 03:59, Pacho Ramos wrote:
Hello
Currently, package maintainers are CCed to security bugs when their are
needed. The problem is that, once maintainers add a fixed version and
tell security team they are ok to get it stabilized, maintainers are
kept CCed until bug is closed by securi
On Wed, 12 Sep 2012 19:59:01 +0200
Pacho Ramos wrote:
> Hello
>
> Currently, package maintainers are CCed to security bugs when their
> are needed. The problem is that, once maintainers add a fixed version
> and tell security team they are ok to get it stabilized, maintainers
> are kept CCed unt
Hello
Currently, package maintainers are CCed to security bugs when their are
needed. The problem is that, once maintainers add a fixed version and
tell security team they are ok to get it stabilized, maintainers are
kept CCed until bug is closed by security team. This usually means
getting a lot
El mié, 12-09-2012 a las 08:44 -0400, Ian Stakenvicius escribió:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 11/09/12 06:23 PM, Rich Freeman wrote:
> > On Tue, Sep 11, 2012 at 5:01 PM, William Hubbs
> > wrote:
> >>
> >> I can agree that a server would probably want a static
> >> c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/09/12 12:58 PM, Zac Medico wrote:
> On 09/12/2012 09:33 AM, Hans de Graaff wrote:
>> On Wed, 2012-09-12 at 08:58 -0400, Ian Stakenvicius wrote:
>>
>>> So essentially what you're saying here is that it might be
>>> worthwhile to look into paral
On 09/12/2012 09:33 AM, Hans de Graaff wrote:
> On Wed, 2012-09-12 at 08:58 -0400, Ian Stakenvicius wrote:
>
>> So essentially what you're saying here is that it might be worthwhile
>> to look into parallelism as a whole and possibly come up with a
>> solution that combines 'emerge --jobs' and bui
On Wed, Sep 12, 2012 at 12:33 PM, Hans de Graaff wrote:
> On Wed, 2012-09-12 at 08:58 -0400, Ian Stakenvicius wrote:
>
> > So essentially what you're saying here is that it might be worthwhile
> > to look into parallelism as a whole and possibly come up with a
> > solution that combines 'emerge -
On Wed, 2012-09-12 at 08:58 -0400, Ian Stakenvicius wrote:
> So essentially what you're saying here is that it might be worthwhile
> to look into parallelism as a whole and possibly come up with a
> solution that combines 'emerge --jobs' and build-system parallelism
> together to maximum benefit?
Il 11/09/2012 18:43, Zac Medico ha scritto:
On 09/11/2012 09:36 AM, viv...@gmail.com wrote:
Dunno where to place this request, but if we go for something like EJOBS
could we also make it phase specific?
So compile, install and test could have a different number of jobs running.
Possibly three di
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/09/12 05:55 AM, Gregory M. Turner wrote:
>
> Note that, effectively, we have this already, and it's called
> "portage". But one could certainly make a case for modularizing it
> better, since, in truth, we are talking about a very common, very
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/09/12 06:23 PM, Rich Freeman wrote:
> On Tue, Sep 11, 2012 at 5:01 PM, William Hubbs
> wrote:
>>
>> I can agree that a server would probably want a static
>> configuration, but all work stations do not use gnome, kde, etc.
>>
>
> Most do no
On 09/12/2012 02:16 AM, Gregory M. Turner wrote:
> In all seriousness, if both of them are sourced, then could one get away
> with something like this?
>
> /etc/make.conf:
> source /etc/portage/make.conf
>
> /etc/portage/make.conf:
> if [[ __GENTOO_MAKE_CONF_ONCE == gotit ]] ; then
> __GENTOO_MAK
On 9/11/2012 9:54 AM, Ian Stakenvicius wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/09/12 12:43 PM, Zac Medico wrote:
On 09/11/2012 09:36 AM, viv...@gmail.com wrote:
Dunno where to place this request, but if we go for something
like EJOBS could we also make it phase specific? S
On 9/10/2012 10:39 PM, Duncan wrote:
Gregory M. Turner posted on Mon, 10 Sep 2012 20:29:53 -0700 as excerpted:
However, IIRC, /etc/make.conf is just ignored by portage if
/etc/portage/make.conf is present, so symlinking, or even better, if
possible, hardlinking those files would probably "do th
Dear all,
since I dont have the time anymore, I've re-assigned the following packages to
maintainer-needed. Please go get them if interested.
app-admin/collectd (*)
app-arch/arj
app-editors/dhex
dev-libs/libcaldav
dev-libs/libofx
dev-util/nvidia-cuda-npp
kde-misc/kcollectd
media-gfx/argyllcms
me
32 matches
Mail list logo
