---
gx86/eclass/python-r1.eclass | 66
1 file changed, 66 insertions(+)
diff --git a/gx86/eclass/python-r1.eclass b/gx86/eclass/python-r1.eclass
index 0d6ef4c..6d4eb33 100644
--- a/gx86/eclass/python-r1.eclass
+++ b/gx86/eclass/python-r1.eclass
@@ -363
And in case anyone wondered, the output looks like this:
* PYTHON_TARGETS <-> USE_PYTHON inconsistency found. This may result
* in missing modules when trying to use Python packages. Please ensure
* that the same implementations are listed in both variables.
*
* Implementation python2_5 disa
Le lundi 05 novembre 2012 à 13:15 +0100, Michał Górny a écrit :
> And in case anyone wondered, the output looks like this:
>
> * PYTHON_TARGETS <-> USE_PYTHON inconsistency found. This may result
> * in missing modules when trying to use Python packages. Please ensure
> * that the same implemen
On Mon, 05 Nov 2012 13:43:50 +0100
Gilles Dartiguelongue wrote:
> Le lundi 05 novembre 2012 à 13:15 +0100, Michał Górny a écrit :
> > And in case anyone wondered, the output looks like this:
> >
> > * PYTHON_TARGETS <-> USE_PYTHON inconsistency found. This may result
> > * in missing modules w
On Thu, Nov 01, 2012 at 07:32:54PM -0700, Diego Elio Pettenò wrote:
> On 01/11/2012 19:23, Steven J. Long wrote:
> > He's right tho: the topic was "Why doesn't your tinderbox work with
> > overlays?" Your response was to insult Arfrever and not actually answer
> > the point.
>
> _Arfrever himself_
On Mon, Nov 5, 2012 at 6:59 AM, Michał Górny wrote:
> ---
> gx86/eclass/python-r1.eclass | 66
>
> 1 file changed, 66 insertions(+)
>
> diff --git a/gx86/eclass/python-r1.eclass b/gx86/eclass/python-r1.eclass
> index 0d6ef4c..6d4eb33 100644
> --- a/gx
On Mon, 5 Nov 2012 10:22:22 -0500
Mike Gilbert wrote:
> On Mon, Nov 5, 2012 at 6:59 AM, Michał Górny wrote:
> > ---
> > gx86/eclass/python-r1.eclass | 66
> >
> > 1 file changed, 66 insertions(+)
> >
> > diff --git a/gx86/eclass/python-r1.eclass b/g
On Mon, Nov 5, 2012 at 10:32 AM, Michał Górny wrote:
> On Mon, 5 Nov 2012 10:22:22 -0500
> Mike Gilbert wrote:
>
>> On Mon, Nov 5, 2012 at 6:59 AM, Michał Górny wrote:
>> > ---
>> > gx86/eclass/python-r1.eclass | 66
>> >
>> > 1 file changed, 66 ins
On 05/11/2012 07:31, Steven J. Long wrote:
> Are you really missing the fact that by testing someone's overlay, the package
> would by definition not be in the tree, and you wouldn't have to file any bugs
> at all, just (automatically) email the output back to the overlay developer?
Which means I
On 11/05/2012 10:39 AM, Diego Elio Pettenò wrote:
> On 05/11/2012 07:31, Steven J. Long wrote:
>> Are you really missing the fact that by testing someone's overlay, the
>> package
>> would by definition not be in the tree, and you wouldn't have to file any
>> bugs
>> at all, just (automatically)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/11/12 12:00 PM, Michael Orlitzky wrote:
>
> 1) Over time, unstable has become too stable (I know, I know).
> People expect things to work, and nobody wants to break working
> systems by committing works-in-progress to ~arch.
>
We have p.mask
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/05/2012 12:15 PM, Ian Stakenvicius wrote:
> On 05/11/12 12:00 PM, Michael Orlitzky wrote:
>
>> 1) Over time, unstable has become too stable (I know, I know).
>> People expect things to work, and nobody wants to break working
>> systems by comm
On 05/11/2012 09:15, Ian Stakenvicius wrote:
> We have p.mask for that, though, so dev's could get in the habit of
> committing and hard-masking things more, rather than using overlays.
Amen.
That's what I've been saying for the past week or so, and before as well.
Get it in p.mask, so that you'
On 05/11/2012 09:32, Michael Orlitzky wrote:
> Being hard masked is a little bit stronger than what I had in mind. I
> was thinking, "no known problems, but it hasn't been tested
> thoroughly." Users with a death wish could run it, and it might work.
> That would leave package.mask for known broken
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A quick grep of the tree:
grep -R "/etc/make.conf" /usr/portage/*/*/*.ebuild
Shows many many ebuilds are still referencing /etc/make.conf instead of
the new location which is /etc/portage/make.conf
Even some eclasses are still doing it:
grep -R "/e
Diego Elio Pettenò posted on Mon, 05 Nov 2012 07:39:19 -0800 as excerpted:
> On 05/11/2012 07:31, Steven J. Long wrote:
>> Are you really missing the fact that by testing someone's overlay, the
>> package would by definition not be in the tree, and you wouldn't have
>> to file any bugs at all, jus
Rick \"Zero_Chaos\" Farina posted on Mon, 05 Nov 2012 15:48:22 -0500 as
excerpted:
> A quick grep of the tree:
>
> grep -R "/etc/make.conf" /usr/portage/*/*/*.ebuild
Quick suggestion. Grep for /etc/portage/make.conf as well, and eliminate
the files that show up in both lists. Untested:
grep
On 05/11/2012 13:45, Duncan wrote:
>
> What about doing overlays, but ONLY one-at-a-time, and ONLY on special-
> request-runs, presumably immediately pre-tree-introduction? Among other
> things that might help for stuff like kde where a whole slew of packages
> are introduced to the tree (and s
On Mon, Nov 05, 2012 at 01:15:45PM +0100, Micha?? G??rny wrote:
> And in case anyone wondered, the output looks like this:
>
> * PYTHON_TARGETS <-> USE_PYTHON inconsistency found. This may result
> * in missing modules when trying to use Python packages. Please ensure
> * that the same implemen
On Mon, Nov 5, 2012 at 5:25 PM, Brian Harring wrote:
> On Mon, Nov 05, 2012 at 01:15:45PM +0100, Micha?? G??rny wrote:
>> And in case anyone wondered, the output looks like this:
>>
>> * PYTHON_TARGETS <-> USE_PYTHON inconsistency found. This may result
>> * in missing modules when trying to use
On Mon, Nov 05, 2012 at 05:50:24PM -0500, Mike Gilbert wrote:
> On Mon, Nov 5, 2012 at 5:25 PM, Brian Harring wrote:
> > On Mon, Nov 05, 2012 at 01:15:45PM +0100, Micha?? G??rny wrote:
> >> And in case anyone wondered, the output looks like this:
> >>
> >> * PYTHON_TARGETS <-> USE_PYTHON inconsis
On Mon, Nov 5, 2012 at 6:34 PM, Brian Harring wrote:
> On Mon, Nov 05, 2012 at 05:50:24PM -0500, Mike Gilbert wrote:
>> On Mon, Nov 5, 2012 at 5:25 PM, Brian Harring wrote:
>> > On Mon, Nov 05, 2012 at 01:15:45PM +0100, Micha?? G??rny wrote:
>> >> And in case anyone wondered, the output looks lik
On Mon, Nov 05, 2012 at 06:54:45PM -0500, Mike Gilbert wrote:
> On Mon, Nov 5, 2012 at 6:34 PM, Brian Harring wrote:
> > This isn't quite what I'm asking for. I want y'all to literally
> > document thus:
> >
> > 1) What your finished solution is going to look like. Users control
> > which implem
On 11/06/12 05:45, Duncan wrote:
> Diego Elio Pettenò posted on Mon, 05 Nov 2012 07:39:19 -0800 as excerpted:
>
>> On 05/11/2012 07:31, Steven J. Long wrote:
>>> Are you really missing the fact that by testing someone's overlay, the
>>> package would by definition not be in the tree, and you would
All,
I would like to make OpenRC-0.11.4 the next stable candidate for OpenRC.
We need it before we can stable a newer genkernel, and releng also needs
it stable for the install cds. Because of this, I am interested in
moving it to stable faster than 30 days (I'm thinking more like 14).
In other w
On Tue, Nov 06, 2012 at 12:02:35AM -0600, William Hubbs wrote:
> In other words, I need testers. So, if you aren't running
> OpenRC-0.11.4,, and you are willing to test for regressions, please
> upgrade and file bugs asap, especially if you find regressions.
Likewise, I'd like to call for testing f
26 matches
Mail list logo
