The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2008-11-09 23h59 UTC.
Removals:
net-dns/resolvconf-gentoo 2008-11-03 13:04:40 armin76
x11-misc/obpager2008-11-03 23:46:13 darkside
x11-themes/lxappearance
On 09-11-2008 19:46:12 +0200, Peter Alfredsen wrote:
> > Ok. What worries me though is that this would result in some systems
> > having libtool files whereas the majority does not. E.g. removing
> > them apparently fixes a problem that then crops up on those systems
> > or something. Can't thin
On Sunday 09 November 2008, Fabian Groffen wrote:
> You could identify ELF a bit more reliable by running file on e.g.
> "${ROOT}/bin/bash", or just by building a list of CHOSTs that you
> know are ELF systems.
D'oh, should have thought of that. See attached patch.
> > > > + debug-
On 09-11-2008 18:34:31 +0200, Peter Alfredsen wrote:
> On Sunday 09 November 2008, Fabian Groffen wrote:
> > On 09-11-2008 18:04:05 +0200, Peter Alfredsen wrote:
> > > + # If this is a non-ELF system, chances are good that the .la
> > > files will be needed. + if type -P scanelf &> /dev/null
> >
On Sunday 09 November 2008, Fabian Groffen wrote:
> On 09-11-2008 18:04:05 +0200, Peter Alfredsen wrote:
> > + # If this is a non-ELF system, chances are good that the .la
> > files will be needed. + if type -P scanelf &> /dev/null
>
> I think this is a not so cool way to check for an ELF sys
On 09-11-2008 18:04:05 +0200, Peter Alfredsen wrote:
> + # If this is a non-ELF system, chances are good that the .la files will
> be needed.
> + if type -P scanelf &> /dev/null
I think this is a not so cool way to check for an ELF system.
> + then
> + debug-print "Scanel
I attach here a proposed new function for eutils.eclass. Review
requested. Thanks to zlin and igli for initial review and suggestions
on #gentoo-dev-help.
--
/PA
--- /usr/portage/eclass/eutils.eclass 2008-09-28 07:06:15.0 +0200
+++ eutils1.eclass 2008-11-06 22:22:51.0 +0100
@@ -1
On Sunday 02 November 2008, Peter Alfredsen wrote:
> The attached patch for bug 238753 makes base.eclass support EAPI 2
> functions.
Applied
--
/PA
signature.asc
Description: This is a digitally signed message part.
Well for myself I found compromise. Although in both proposals as I see
you've omitted part where you'll discuss how you are going to implement
this feature, implementing this feature as eclass addresses most of my
concerns, since:
1. ebuild's syntax does not change
2. people will have to inherit
Hello,
El dom, 09-11-2008 a las 15:39 +0300, Peter Volkov escribió:
>
> 1. Functions we have now are much more flexible then proposed arrays. Do
> I need to think of some example of code that is impossible to do with
> arrays but still possible with functions?
>
The same concern was raised in t
On Sun, Nov 09, 2008 at 03:39:12PM +0300, Peter Volkov wrote:
> В Сбт, 08/11/2008 в 17:20 -0500, Thomas Anderson пишет:
> > This is a reposting of a call for discussion on DEFAULT_* variables.
> > The original discussion was at [1].
> 1. Functions we have now are much more flexible then proposed ar
В Сбт, 08/11/2008 в 17:20 -0500, Thomas Anderson пишет:
> This is a reposting of a call for discussion on DEFAULT_* variables.
> The original discussion was at [1].
How does this proposal answers concerns raised during last discussion?
I did my best and reread all the discussions and both proposa
Daniel Drake <[EMAIL PROTECTED]> writes:
> dev-dotnet/evolution-sharp
I was going to ask you about this last week, I guess I'll look into it
(although it makes me feel dirty to work with .NET stuff, I've been
working with worse stuff :P).
--
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/
13 matches
Mail list logo
