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
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
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?
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
-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
willi...@gentoo.org wrote:
I can agree that a server would probably want a static
configuration, but all work stations do not use gnome, kde, etc.
-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
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
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?
On Wed, Sep 12, 2012 at 12:33 PM, Hans de Graaff gra...@gentoo.org 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
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
-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 parallelism as
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
willi...@gentoo.org wrote:
I can agree that a server would probably want a static
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
On Wed, 12 Sep 2012 19:59:01 +0200
Pacho Ramos pa...@gentoo.org 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
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
On Wed, Sep 12, 2012 at 2:29 PM, Jeroen Roovers j...@gentoo.org 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
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,
El mié, 12-09-2012 a las 20:29 +0200, Jeroen Roovers escribió:
On Wed, 12 Sep 2012 19:59:01 +0200
Pacho Ramos pa...@gentoo.org 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
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 are ok to
El mié, 12-09-2012 a las 14:42 -0400, Rich Freeman escribió:
On Wed, Sep 12, 2012 at 2:29 PM, Jeroen Roovers j...@gentoo.org 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
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 under the
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
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 fixed version
On Wed, 12 Sep 2012 20:53:20 +0200
Pacho Ramos pa...@gentoo.org 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
On 13 September 2012 09:43, Jeroen Roovers j...@gentoo.org wrote:
On Wed, 12 Sep 2012 20:53:20 +0200
Pacho Ramos pa...@gentoo.org 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,
On 13 September 2012 04:36, Brian Harring ferri...@gmail.com 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),
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 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 address 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=recur
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's a bit of a
On Tue, 11 Sep 2012 14:33:51 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:
Could a number of folks familiar with both portage AND bash completion
help out the shell-tools herd (no specific maintainer specified in
metadata) with app-shell/gentoo-bashcomp bugs?
It seems to have accumulated
El jue, 02-08-2012 a las 12:34 -0700, Zac Medico escribió:
On 08/01/2012 11:36 PM, Pacho Ramos wrote:
El mié, 01-08-2012 a las 16:14 -0700, Zac Medico escribió:
On 08/01/2012 03:19 AM, Pacho Ramos wrote:
On every openrc update I get dispatch-conf wanting to revert all my
changes in
32 matches
Mail list logo
