> On Thu, 30 Jun 2011, William Hubbs wrote:
> Please discuss. Did I leave out any steps? Are there any points I
> have left out besides the time window between steps 2 and 3? Should
> there be a time window before removing baselayout-1? What about
> between steps 1 and 2? What do you consider
Nirbheek Chauhan wrote:
On Fri, Jul 1, 2011 at 11:03 AM, Dale wrote:
William Hubbs wrote:
As a user, if a person hasn't upgraded in about 6 months, they may as well
reinstall anyway. That is usually the advice given on -user. After a year
without updating, it is certainly easier and most
On Fri, Jul 1, 2011 at 11:03 AM, Dale wrote:
> William Hubbs wrote:
> As a user, if a person hasn't upgraded in about 6 months, they may as well
> reinstall anyway. That is usually the advice given on -user. After a year
> without updating, it is certainly easier and most likely faster to
> rein
William Hubbs wrote:
All,
the time has come when baselayout-2.x and openrc are stable on all of
our architectures. That means that we should look into removing
baselayout-1 from the tree, removing support for it from our init
scripts and removing support for migration from the openrc
ebuilds.
1
All,
the time has come when baselayout-2.x and openrc are stable on all of
our architectures. That means that we should look into removing
baselayout-1 from the tree, removing support for it from our init
scripts and removing support for migration from the openrc
ebuilds.
1. we can remove baselay
On Thu, Jun 30, 2011 at 17:30, Michał Górny wrote:
> On Thu, 30 Jun 2011 17:16:14 -0400 Mike Frysinger wrote:
>> On Thu, Jun 30, 2011 at 17:14, Michał Górny wrote:
>> > On Wed, 29 Jun 2011 23:47:42 -0400 Mike Frysinger wrote:
>> >> On Wednesday, June 29, 2011 22:19:09 Michał Górny wrote:
>> >> > On
On Thu, Jun 30, 2011 at 11:30:51PM +0200, Michał Górny wrote:
> On Thu, 30 Jun 2011 17:16:14 -0400
> Mike Frysinger wrote:
>
> > On Thu, Jun 30, 2011 at 17:14, Michał Górny wrote:
> > > On Wed, 29 Jun 2011 23:47:42 -0400 Mike Frysinger wrote:
> > >> On Wednesday, June 29, 2011 22:19:09 Michał Gór
On Thu, 30 Jun 2011 17:16:14 -0400
Mike Frysinger wrote:
> On Thu, Jun 30, 2011 at 17:14, Michał Górny wrote:
> > On Wed, 29 Jun 2011 23:47:42 -0400 Mike Frysinger wrote:
> >> On Wednesday, June 29, 2011 22:19:09 Michał Górny wrote:
> >> > On Wed, 29 Jun 2011 16:46:13 -0500 William Hubbs wrote:
>
After some thinking, I'd like to re-state the USE_EXPAND variant
as having the following advantages:
1) backwards compatible -- we can make the new feature optional for
older EAPIs, making it useful for older ebuilds as well. If a PM
doesn't support it, it will just treat them as ordinary USE;
2)
On Thu, Jun 30, 2011 at 17:14, Michał Górny wrote:
> On Wed, 29 Jun 2011 23:47:42 -0400 Mike Frysinger wrote:
>> On Wednesday, June 29, 2011 22:19:09 Michał Górny wrote:
>> > On Wed, 29 Jun 2011 16:46:13 -0500 William Hubbs wrote:
>> > > Ok, the option that I'm looking at now is to set up openrc so
On Wed, 29 Jun 2011 23:47:42 -0400
Mike Frysinger wrote:
> On Wednesday, June 29, 2011 22:19:09 Michał Górny wrote:
> > On Wed, 29 Jun 2011 16:46:13 -0500 William Hubbs wrote:
> > > Ok, the option that I'm looking at now is to set up openrc so
> > > that the init scripts are optional and whether
On Thursday 30 of June 2011 20:54:21 Robin H. Johnson wrote:
> On Thu, Jun 30, 2011 at 10:40:26PM +0400, Alexey Shvetsov wrote:
> > I'm working on putting infiniband support to main tree. Currently
> > infiniband related stuff hosted in science overlay in sys-infiniband
> > [1] category (this categ
On Thu, Jun 30, 2011 at 10:40:26PM +0400, Alexey Shvetsov wrote:
> I'm working on putting infiniband support to main tree. Currently infiniband
> related stuff hosted in science overlay in sys-infiniband [1] category (this
> category currently contains ~25 packages but they will be ~40) so i wann
On Thu, Jun 30, 2011 at 15:13, Alexey Shvetsov wrote:
> On Thursday 30 of June 2011 14:47:06 Mike Frysinger wrote:
>> On Thu, Jun 30, 2011 at 14:40, Alexey Shvetsov wrote:
>> > Also i'm going to add USE_EXPAND for infiniband userspace drivers:
>> > libmlx4
>> > libmthca
>> > libehca
>> > libcxgb3
>
On Thursday 30 of June 2011 14:47:06 Mike Frysinger wrote:
> On Thu, Jun 30, 2011 at 14:40, Alexey Shvetsov wrote:
> > Also i'm going to add USE_EXPAND for infiniband userspace drivers:
> > libmlx4
> > libmthca
> > libehca
> > libcxgb3
use will be something like OPENIB_DRIVERS="mlx4 mthca ehca cxg
On Thu, Jun 30, 2011 at 14:40, Alexey Shvetsov wrote:
> Also i'm going to add USE_EXPAND for infiniband userspace drivers:
> libmlx4
> libmthca
> libehca
> libcxgb3
should it be based on the hardware family rather than the lib name ?
> Any objections about moving this stuff to tree?
i object to
Hi all!
I'm working on putting infiniband support to main tree. Currently infiniband
related stuff hosted in science overlay in sys-infiniband [1] category (this
category currently contains ~25 packages but they will be ~40) so i wanna move
them as whole category. Also i'm going to add USE_EXPA
Hi Paul and everyone,
On Thu, Jun 30, 2011 at 11:04:04AM -0400, Mike Frysinger wrote:
> On Thu, Jun 30, 2011 at 08:58, Paul de Vrieze wrote:
> > Why can't we just split up functions.sh into "/lib/output.sh"
>
> we're not changing the file name
I just made a case on the bug for having a separate
On Jun 30, 2011 11:06 AM, "Mike Frysinger" wrote:
>
> we're not splitting the source trees. the reasons have already been
> detailed in the bug open on the topic.
> -mike
>
I think we're generally aiming for perfection when we should be pragmatic.
The proposed solution isn't ideal, but is workab
On Thu, Jun 30, 2011 at 08:58, Paul de Vrieze wrote:
> Why can't we just split up functions.sh into "/lib/output.sh"
we're not changing the file name
> containing the init script independent (but often gentoo specific)
> output stuff, and have functions.sh source this. Output.sh would be
> provid
On 30 June 2011 04:47, Mike Frysinger wrote:
>
> On Wednesday, June 29, 2011 22:19:09 Michał Górny wrote:
> > On Wed, 29 Jun 2011 16:46:13 -0500 William Hubbs wrote:
> > > Ok, the option that I'm looking at now is to set up openrc so that the
> > > init scripts are optional and whether or not they
21 matches
Mail list logo
