Le 08/02/2010 03:24, Mike Frysinger a écrit :
> if we wanted to specifically target semi-common errors (and i think 'epatch'
> w/out eutils.eclass falls into this category), then a repoman check would be
> good.
>
> it might also be useful to add a default epatch() to the initial env that
> wou
On Mon, Feb 08, 2010 at 05:23:03AM +, Robin H. Johnson wrote:
> On Sun, Feb 07, 2010 at 05:02:22PM -0800, Brian Harring wrote:
> > On Sun, Jan 31, 2010 at 10:04:40AM +, Robin H. Johnson wrote:
> > > Changes:
> > > - This GLEP can stand independently of GLEP58.
> > > - Add XZ to compression
On Sun, Feb 07, 2010 at 05:02:22PM -0800, Brian Harring wrote:
> On Sun, Jan 31, 2010 at 10:04:40AM +, Robin H. Johnson wrote:
> > Changes:
> > - This GLEP can stand independently of GLEP58.
> > - Add XZ to compression types list.
> > - Move cutoff to 32KiB. Provide size example w/ 32KiB+gzip.
On Sunday 07 February 2010 17:19:43 Zac Medico wrote:
> On 02/07/2010 01:10 PM, Stelian Ionescu wrote:
> > Wouldn't it be a good idea to use "set -e" in the ebuild environment ?
> > I've seen cases of ebuilds calling epatch without inheriting from eutils
> > which compiled and installed (apparently
On Sunday 07 February 2010 16:10:10 Stelian Ionescu wrote:
> Wouldn't it be a good idea to use "set -e" in the ebuild environment ?
> I've seen cases of ebuilds calling epatch without inheriting from eutils
> which compiled and installed (apparently) fine but possibly broken
> binaries.
this is no
On Sun, Jan 31, 2010 at 10:04:40AM +, Robin H. Johnson wrote:
> Changes:
> - This GLEP can stand independently of GLEP58.
> - Add XZ to compression types list.
> - Move cutoff to 32KiB. Provide size example w/ 32KiB+gzip.
> - Split specification into generation and validation.
>
One concern w
On Sun, 2010-02-07 at 14:19 -0800, Zac Medico wrote:
> On 02/07/2010 01:10 PM, Stelian Ionescu wrote:
> > Wouldn't it be a good idea to use "set -e" in the ebuild environment ?
> > I've seen cases of ebuilds calling epatch without inheriting from eutils
> > which compiled and installed (apparently)
El 07/02/2010, a las 18:19, Zac Medico escribió:
On 02/07/2010 01:10 PM, Stelian Ionescu wrote:
Wouldn't it be a good idea to use "set -e" in the ebuild
environment ?
I've seen cases of ebuilds calling epatch without inheriting from
eutils
which compiled and installed (apparently) fine but
On Sun, Feb 07, 2010 at 12:17:17PM -0800, Zac Medico wrote:
> I noticed that this generates a depedency like "|| (
> =dev-lang/python-2.7* =dev-lang/python-2.6* )" which is very similar
> to the way that QT3VERSIONS works in qt3.eclass. One thing that is
> sub-optimal about these types of dependenc
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2010-02-07 23h59 UTC.
Removals:
dev-ruby/ruby-mmap 2010-02-01 10:27:46 flameeyes
media-libs/libdsp 2010-02-01 14:44:59 vostorga
x11-terms/x3270
On 02/07/2010 01:10 PM, Stelian Ionescu wrote:
> Wouldn't it be a good idea to use "set -e" in the ebuild environment ?
> I've seen cases of ebuilds calling epatch without inheriting from eutils
> which compiled and installed (apparently) fine but possibly broken
> binaries. Examples of cases where
Wouldn't it be a good idea to use "set -e" in the ebuild environment ?
I've seen cases of ebuilds calling epatch without inheriting from eutils
which compiled and installed (apparently) fine but possibly broken
binaries. Examples of cases where "set -e" would have helped: 303849,
297063, 260279, 22
On 02/06/2010 03:03 AM, Arfrever Frehtes Taifersar Arahesis wrote:
> 2010-02-05 17:40:00 Arfrever Frehtes Taifersar Arahesis napisał(a):
>> - Dependency on Python 2 should be set correctly. You can specify it
>> directly in
>> {,R}DEPEND or use PYTHON_DEPEND.
>>
>> Example:
>> PYTHON_D
On Saturday 06 February 2010 13:03:11 Arfrever Frehtes Taifersar Arahesis
wrote:
> 2010-02-05 17:40:00 Arfrever Frehtes Taifersar Arahesis napisał(a):
> > - Dependency on Python 2 should be set correctly. You can specify it
> > directly in {,R}DEPEND or use PYTHON_DEPEND.
> >
> > Example:
> >
On Saturday 06 February 2010 19:22:47 Samuli Suominen wrote:
> While we have few devs listed in desktop-misc, nobody is really looking
> at the bugs in general so it's like a clone of maintainer-needed alias
> at the moment... The bug count has escalated in /a year/ from /5 to 83/
> (only counting
15 matches
Mail list logo
