On Tue, 10 Mar 2009 17:11:56 +0100
Christian Faulhammer wrote:
> Ciaran McCreesh :
> > Then this is a legitimate problem that someone needs to know about
> > and fix. So having src_test turned on globally is a *good* thing.
> >
> [...]
> >
> > Again, finding this is good.
> [...]
> >
> > And if
On Tue, 10 Mar 2009 17:00:05 +0100
Christian Faulhammer wrote:
> > Well, the alternative is to drop src_test all together. If a test
> > failure is meaningless, having the test is meaningless.
>
> No, some software like in sci-* has test suites that a user wants to
> run probably before producti
On Mon, 9 Mar 2009 20:58:40 -0700
Alec Warner wrote:
> You can't test everything. I think for a small project like exherbo
> where everyone basically sees eye to eye on a number of ideas this
> works great. Everyone agrees testing is super and they will fix
> broken tests or RESTRICT them. But
On Tue, 10 Mar 2009 00:25:49 +0100
Christian Faulhammer wrote:
> > Uh, you *are* testing things that use a library before you stable
> > that library, right?
>
> When I was an architecture developer I tried to. But when
> stabilising a minor version of curl (for example), testing all
> reverse
On Mon, Mar 9, 2009 at 3:25 PM, Ciaran McCreesh
wrote:
> On Mon, 9 Mar 2009 23:20:03 +0100
> Christian Faulhammer wrote:
>> Package A goes stable, test suite passes. Package B (a dependency of
>> A) goes stable in a newer version, which will cause A to not merge in
>> stable profile. This happ
On Mon, 9 Mar 2009 23:24:15 +0100
Maciej Mrozowski wrote:
> Unfortunately upstream tends to think of tests in very relaxed way.
And for those upstreams that do, you RESTRICT=test, or better yet
filter out dodgy tests. Which is what you should be doing currently
anyway -- the difference is, with E
On Mon, 9 Mar 2009 23:20:03 +0100
Christian Faulhammer wrote:
> Package A goes stable, test suite passes. Package B (a dependency of
> A) goes stable in a newer version, which will cause A to not merge in
> stable profile. This happens all the time and is no special case.
Uh, you *are* testing
On Monday 09 of March 2009 22:36:33 Ciaran McCreesh wrote:
> On Mon, 9 Mar 2009 22:33:11 +0100
>
> Christian Faulhammer wrote:
> > Ciaran McCreesh :
> > > Next, some probably easy but long standing features:
> > >
> > > * src_test run unless RESTRICTed or explicitly disabled by the user
> > > (bug
On Mon, 9 Mar 2009 22:33:11 +0100
Christian Faulhammer wrote:
> Ciaran McCreesh :
> > Next, some probably easy but long standing features:
> >
> > * src_test run unless RESTRICTed or explicitly disabled by the user
> > (bug 184812)
>
> A big no. This will lead to many failures on user systems,
Am Montag, den 09.03.2009, 10:06 +0100 schrieb Christian Faulhammer:
> Hi,
>
> Daniel Pielmeier :
>
> > 2009/3/9 Christian Faulhammer :
> > >
> > > I don't know if there is a bug somewhere (I did not find one), but
> > > what about having the possibility to ask for one out many USE flags
> > > o
2009/3/9 Christian Faulhammer :
> Hi,
>
> Daniel Pielmeier :
>>
>> || ( dev-lang/python[berkdb] dev-lang/python[sqlite] )
>
> That's the solution currently and not the optimum.
>
I have discussed this yesterday with loki_val, and workaround would be
using a useflag for one database backend and if
2009/3/9 Christian Faulhammer :
>
> I don't know if there is a bug somewhere (I did not find one), but
> what about having the possibility to ask for one out many USE flags of
> a dependency. For example app-misc/gramps needs dev-lang/python with
> USE=berkdb or USE=sqlite, but Portage won't tell
12 matches
Mail list logo
