On Sun, 2014-01-12 at 19:07 -0800, Brian Dolbec wrote:
> Our team is now, I think quite well rounded, with interests in different
> areas of portage and it's utilities.
>
> We have also converted most of the old www.gentoo.org project pages to
> the wiki [1], still a few more to go.
>
> The por
On Sun, 2014-01-05 at 21:33 -0800, Brian Dolbec wrote:
> This is a general call for developers to join the portage development
> team.
>
> aka: Recruiting Drive
>
> If you have some "Good" python and/or bash skills and want/need to or
> already know portage's internals. WE NEED YOU!
>
I want t
On Sun, 12 Jan 2014 01:53:47 -0600
Ryan Hill wrote:
> While I'm adding USE defaults to toolchain.eclass and moving them out of the
> profiles, I thought now would be a good time to review a couple default flag
> settings.
Okay, we'll be dropping fortran from the profiles and enabling it as a def
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2014-01-12 23h59 UTC.
Removals:
dev-php/DBUnit 2014-01-06 14:31:09 mabi
dev-php/PEAR-File_PDF 2014-01-06 14:40:34 mabi
dev-java/jdictrayapi
bug https://bugs.gentoo.org/show_bug.cgi?id=494210
From: Julian Ospald
Date: Fri Dec 13 21:14:01 UTC 2013
Subject: respect ECONF_SOURCE
--- eclass/games.eclass
+++ eclass/games.eclass
@@ -153,7 +153,7 @@
}
games_src_configure() {
- [[ -x ./configure ]] && egamesconf
+ [[ -x "${ECONF_SOURCE:-.
On Sun, Jan 12, 2014 at 01:53:47AM -0600, Ryan Hill wrote:
> While I'm adding USE defaults to toolchain.eclass and moving them out of the
> profiles, I thought now would be a good time to review a couple default flag
> settings.
>
> mudflap:
> This is currently enabled by default but I'd like to d
Hello Naohiro,
Saturday, January 11, 2014, 7:00:58 PM, you wrote:
This one was close.
It would be great to have your help. Can you if need be
write a plugin for portage to send|receive portage data from|to
the servers?
I'm not well with Python. We would need a plug-in for the
portage to send
On Sun, Jan 12, 2014 at 1:53 AM, Ryan Hill wrote:
>
> fortran:
> Do we want to keep enabling fortran by default? The majority of users will
> never get the urge to install a fortran package, and the fortran eclass
> handles
> those that do. I think it should be treated as all the other optional
On Sat, Jan 11, 2014 at 11:53 PM, Ryan Hill wrote:
> While I'm adding USE defaults to toolchain.eclass and moving them out of the
> profiles, I thought now would be a good time to review a couple default flag
> settings.
>
> mudflap:
> This is currently enabled by default but I'd like to disable i
On 01/12/2014 02:53 AM, Ryan Hill wrote:
> fortran:
> Do we want to keep enabling fortran by default? The majority of users will
> never get the urge to install a fortran package, and the fortran eclass
> handles
> those that do. I think it should be treated as all the other optional
> languages
On Sun, 12 Jan 2014 11:08:18 +0100
Michał Górny wrote:
> Dnia 2014-01-12, o godz. 03:50:53
> Ryan Hill napisał(a):
> > Bootstrapping makes distcc impossible, and you can't bootstrap these days
> > without building C and C++. Even if you're not bootstrapping, the back and
> > middle ends are sh
Am Sonntag, 12. Januar 2014, 08:53:47 schrieb Ryan Hill:
> fortran:
> Do we want to keep enabling fortran by default? The majority of users will
> never get the urge to install a fortran package, and the fortran eclass
> handles those that do. I think it should be treated as all the other
> optio
On Wed, Jan 08, 2014, Rick "Zero_Chaos" Farina wrote:
> Or we could just stop randomly moving libs across the system and
> breaking things then hackmeating things back to a "working" state with
> gen_ld_script.
>
> The whole reason for having gen_ld_script is because people wanted
> dynamic libs i
On Fri, Jan 10, 2014 Igor wrote:
> I've been using C/C++ since school it's fast, even bad code is working fast.
>
> I WOULD NEVER BELIVE PYTHON IS AS FAST AS C++ with math algorithms
> that do calculate staff and not call functions from pre-complied
> objects written in C/C++.
I would never belie
Hello Naohiro,
Saturday, January 11, 2014, 7:00:58 PM, you wrote:
Thanks! I'll peek into it today.
Emery Hemingway all so generously offered his help.
What I plan to do is to share the system design with the people who thinks
the same. I won't mind if either of us will implement it when it's
Dnia 2014-01-12, o godz. 03:50:53
Ryan Hill napisał(a):
> On Sun, 12 Jan 2014 09:24:20 +0100
> Michał Górny wrote:
>
> > Dnia 2014-01-12, o godz. 01:53:47
> > Ryan Hill napisał(a):
> >
> > > fortran:
> > > Do we want to keep enabling fortran by default? The majority of users
> > > will
> >
On Sun, 12 Jan 2014 09:24:20 +0100
Michał Górny wrote:
> Dnia 2014-01-12, o godz. 01:53:47
> Ryan Hill napisał(a):
>
> > fortran:
> > Do we want to keep enabling fortran by default? The majority of users will
> > never get the urge to install a fortran package, and the fortran eclass
> > handl
On Sun, 12 Jan 2014 09:40:01 +0100
Pacho Ramos wrote:
> I was also wondering about what we prefer if Michal's suggestion is not
> possible:
> - Build support for other langs by default -> More time when we need to
> emerge gcc or update it but less time as we don't need to rebuild for
> that (I r
El dom, 12-01-2014 a las 09:24 +0100, Michał Górny escribió:
> Dnia 2014-01-12, o godz. 01:53:47
> Ryan Hill napisał(a):
>
> > fortran:
> > Do we want to keep enabling fortran by default? The majority of users will
> > never get the urge to install a fortran package, and the fortran eclass
> >
Dnia 2014-01-12, o godz. 01:53:47
Ryan Hill napisał(a):
> fortran:
> Do we want to keep enabling fortran by default? The majority of users will
> never get the urge to install a fortran package, and the fortran eclass
> handles
> those that do. I think it should be treated as all the other opt
20 matches
Mail list logo
