Hi folks,
I've been told that my use of eblits in dev-lang/php is something I
should get rid of as soon as possible. Suggested alternative by ferring:
use elibs.
So here goes: I want to see GLEP33[1] implemented in portage, so I can
shift the eblits core and currently global functions into elibs
On Mon, Aug 02, 2010 at 11:56:08AM +0200, Matti Bickel wrote:
> Hi folks,
>
> I've been told that my use of eblits in dev-lang/php is something I
> should get rid of as soon as possible. Suggested alternative by ferring:
> use elibs.
>
> So here goes: I want to see GLEP33[1] implemented in portag
On 2 August 2010 12:11, Brian Harring wrote:
> On Mon, Aug 02, 2010 at 11:56:08AM +0200, Matti Bickel wrote:
>> Hi folks,
>>
>> I've been told that my use of eblits in dev-lang/php is something I
>> should get rid of as soon as possible. Suggested alternative by ferring:
>> use elibs.
There's a c
On Monday, August 02, 2010 05:56:08 Matti Bickel wrote:
> I've been told that my use of eblits in dev-lang/php is something I
> should get rid of as soon as possible.
current eblits support isnt going anywhere. so dont waste time trying to
change code if there is no real alternative. see Bug 32
On Mon, 02 Aug 2010 11:56:08 +0200
Matti Bickel wrote:
> I've been told that my use of eblits in dev-lang/php is something I
> should get rid of as soon as possible. Suggested alternative by
> ferring: use elibs.
>
> So here goes: I want to see GLEP33[1] implemented in portage, so I can
> shift t
2010-07-31 22:25:26 Petteri Räty napisał(a):
> On 07/31/2010 11:10 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> >>
> >> If the variable is set but not exported then it is local to the shell
> >> env. When bash goes to exec() python the local shell variables are
> >> not in the env; so os.envir
A milder warning will be printed.
--
Arfrever Frehtes Taifersar Arahesis
--- python.eclass
+++ python.eclass
@@ -355,6 +355,8 @@
# Check if phase is pkg_setup().
[[ "${EBUILD_PHASE}" != "setup" ]] && die "${FUNCNAME}() can be used only in pkg_setup() phase"
+ local locale
+
if [[ "$#" -ne
On Mon, Aug 02, 2010 at 11:02:20PM +0200, Arfrever Frehtes Taifersar Arahesis
wrote:
> It would have to be parsed using e.g. grep and sed. It's easier to call
> Python in this case.
It's even easier not to.
> The call to Python is sufficiently fast:
>
> $ time python -c 'import os; print(os.en
On 08/02/2010 08:16 PM, David Leverton wrote:
> On 2 August 2010 12:11, Brian Harring wrote:
>> On Mon, Aug 02, 2010 at 11:56:08AM +0200, Matti Bickel wrote:
>>> Hi folks,
>>>
>>> I've been told that my use of eblits in dev-lang/php is something
>>> I should get rid of as soon as possible. Sugges
the env lookup is still way more complicated than it needs to be:
locale=${LC_ALL:-${LC_CTYPE:-${LANG}}}
it is not possible for these variables to be set but not exported unless an
ebuild is doing it, and those are broken anyways.
the message should also reference an open bug report for
On 08/02/2010 09:51 PM, Mike Frysinger wrote:
> On Monday, August 02, 2010 05:56:08 Matti Bickel wrote:
>> I've been told that my use of eblits in dev-lang/php is something I
>> should get rid of as soon as possible.
>
> current eblits support isnt going anywhere. so dont waste time trying to
>
On 08/02/2010 10:15 PM, Ciaran McCreesh wrote:
> Aren't you really after per-package eclasses, not elibs?
Yes. I don't care whether the snippets may affect metadata. They already
don't (at one time they did, but we got warned that that's illegal -
that's why php-5.3 ebuilds have their metadata fol
On Mon, 2 Aug 2010 23:18:59 +0200
Arfrever Frehtes Taifersar Arahesis wrote:
> A milder warning will be printed.
I distinctly remember several voices being raised in this thread very
recently, suggesting if not demanding that you should not convey a
message like that at all, but fix the affected
On Monday, August 02, 2010 17:47:01 Matti Bickel wrote:
> On 08/02/2010 09:51 PM, Mike Frysinger wrote:
> > On Monday, August 02, 2010 05:56:08 Matti Bickel wrote:
> >> I've been told that my use of eblits in dev-lang/php is something I
> >> should get rid of as soon as possible.
> >
> > current e
On Mon, 2 Aug 2010 23:18:59 +0200
Arfrever Frehtes Taifersar Arahesis wrote:
> + ewarn "exceptions. It is recommended to use a UTF-8
> locale to avoid problems."
> + ewarn "See http://www.gentoo.org/doc/en/utf-8.xml
> for information on how to change locale."
In fact the
On 2 August 2010 22:40, Matti Bickel wrote:
> On 08/02/2010 08:16 PM, David Leverton wrote:
>> If so, it sounds like what you really want is per-package eclasses
>> (maybe with elibs as well to hold the non-metadata code), which
>> aren't covered by GLEP33 but ought to be easy enough to add.
>
> I
On 08/03/2010 12:17 AM, David Leverton wrote:
> On 2 August 2010 22:40, Matti Bickel wrote:
>> On 08/02/2010 08:16 PM, David Leverton wrote:
>>> If so, it sounds like what you really want is per-package eclasses
>>> (maybe with elibs as well to hold the non-metadata code), which
>>> aren't covered
On Mon, Aug 02, 2010 at 11:18:59PM +0200, Arfrever Frehtes Taifersar Arahesis
wrote:
> A milder warning will be printed.
Guessing you didn't get the part about "no warning should be put in"
that everyone stated? You're ignoring that this message also will
make users think that switching their
> Modified: ChangeLog
> Removed: python-3.1.2_p20100801.ebuild
> python-2.7_p20100801.ebuild
> python-2.6.5_p20100801.ebuild
> Log:
> remove the backported versions; they're autogenerated, obviously
> not tested for 2
> EAPI=2
> -
> inherit eutils
>
> DESCRIPTION="Mailfilter is a utility to get rid of unwanted spam mails"
> @@ -19,16 +18,16 @@
> RDEPEND=""
>
> src_prepare() {
> - epatch "${FILESDIR}"/0.8.2-gcc44.patch
> + epatch "${FILESDIR}"/0.8.2-gcc44.patch \
> + "${FILESDIR}"/0.8
20 matches
Mail list logo
