Re: [e-users] Gentoo Overlay ebuild issue

2012-08-06 Thread Mick
On Monday 06 Aug 2012 01:00:48 Carsten Haitzler wrote:
 On Sun, 05 Aug 2012 16:24:22 -0500 SndChaser sndcha...@cerebralrift.org
 said:
 
 it is only gentoo specific because gentoo loves to play with configure
 options that are not tested normally. as a result of this kind of
 behaviour we are planning to remove tonnes of build options. it's too much
 overhead to manage.

Yes, too many options cause exponential probabilities that something will 
break.  However, sane defaults by ebuild devs should get expected results.

Other than a buggy ebuild, there are always over-zealous users who tweak their 
options to destruction, but they soon learn that they get to keep both pieces.  
Those who stay with Gentoo and intentionally change their flags also learn how 
to fix what they borked.  So they can be safely ignored.  ;-)

-- 
Regards,
Mick
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users


Re: [e-users] Gentoo Overlay ebuild issue

2012-08-06 Thread The Rasterman
On Mon, 6 Aug 2012 08:48:45 +0100 Mick michaelkintz...@gmail.com said:

 On Monday 06 Aug 2012 01:00:48 Carsten Haitzler wrote:
  On Sun, 05 Aug 2012 16:24:22 -0500 SndChaser sndcha...@cerebralrift.org
  said:
  
  it is only gentoo specific because gentoo loves to play with configure
  options that are not tested normally. as a result of this kind of
  behaviour we are planning to remove tonnes of build options. it's too much
  overhead to manage.
 
 Yes, too many options cause exponential probabilities that something will 
 break.  However, sane defaults by ebuild devs should get expected results.

if gentoo didn't turn on building of enignes that are OFF by default... u'd be
fine. :)

 Other than a buggy ebuild, there are always over-zealous users who tweak
 their options to destruction, but they soon learn that they get to keep both
 pieces. Those who stay with Gentoo and intentionally change their flags also
 learn how to fix what they borked.  So they can be safely ignored.  ;-)

actually both gentoo ebuild users and the tweakers end up on our doorstep
asking us for help with their tweaked builds. on our irc/email lists. though
it's nice to help - we help again and again and repeat ourselves that those
options are for people who know exactly what they are doing with the option. if
u dont know then accept defaults without a --enable or --disable in sight. :) u
do more than that then deal with your own problems - they never do though. we
end up with them. so the future is many fewer options. u'll be patching src to
change things and that tends to be a barrier high enough to keep the tweakers
out :)

-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users


Re: [e-users] Gentoo Overlay ebuild issue

2012-08-06 Thread Alan McKinnon
On Mon, 6 Aug 2012 17:45:36 +0900
Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote:

 actually both gentoo ebuild users and the tweakers end up on our
 doorstep asking us for help with their tweaked builds. on our
 irc/email lists.


We call those people ricers

Maybe you should follow our lead on the gentoo user lists - we help out
ricers as and when we feel like it but mostly just tell them to put
everything back to stock and observe how stuff now works.

Myself, I've been using e17 on gentoo for 6 years or more and I've
used all 3 well-known overlays. Never had a problem with them yet worth
mentioning.

-- 
Alan McKinnon
alan.mckin...@gmail.com


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users


Re: [e-users] Gentoo Overlay ebuild issue

2012-08-06 Thread The Rasterman
On Mon, 6 Aug 2012 12:18:56 +0200 Alan McKinnon alan.mckin...@gmail.com said:

 On Mon, 6 Aug 2012 17:45:36 +0900
 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote:
 
  actually both gentoo ebuild users and the tweakers end up on our
  doorstep asking us for help with their tweaked builds. on our
  irc/email lists.
 
 
 We call those people ricers
 
 Maybe you should follow our lead on the gentoo user lists - we help out
 ricers as and when we feel like it but mostly just tell them to put
 everything back to stock and observe how stuff now works.
 
 Myself, I've been using e17 on gentoo for 6 years or more and I've
 used all 3 well-known overlays. Never had a problem with them yet worth
 mentioning.

time to make this a rice free zone! :)

-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users


Re: [e-users] Gentoo Overlay ebuild issue

2012-08-06 Thread P Purkayastha
On 08/06/2012 04:45 PM, Carsten Haitzler (The Rasterman) wrote:
 actually both gentoo ebuild users and the tweakers end up on our doorstep
 asking us for help with their tweaked builds. on our irc/email lists. though
 it's nice to help - we help again and again and repeat ourselves that those
 options are for people who know exactly what they are doing with the option. 
 if
 u dont know then accept defaults without a --enable or --disable in sight. :) 
 u
 do more than that then deal with your own problems - they never do though. we
 end up with them. so the future is many fewer options. u'll be patching src to
 change things and that tends to be a barrier high enough to keep the tweakers
 out :)


That's not quite true. At least with *good* ebuilds in current Gentoo. 
*Good* ebuilds themselves provides configure options such that the 
default configure options are sane. For example look at the default 
options for evas:

~» eix -e evas
[I] media-libs/evas
  Available versions:  (~)1.0.1 (~)1.1.0 (~)1.2.1 (**){tbz2}[1] 
{X altivec bidi +bmp +cache directfb doc +eet fbcon +fontconfig gif gles 
+ico +jpeg mmx nls opengl +png +ppm +psd sdl sse sse3 static-libs svg 
tga +threads tiff xcb xpm}


You see all the + things? It means that those configure options (USE 
flags in Gentoo terminology) are all enabled by default and the rest are 
disabled by default. This means that if the user is not a ricer, then 
he/she will be compiling evas with just the options that are not likely 
to break evas. If the user is a ricer, he/she will tweak around with all 
the configure flags irrespective of the linux distro. Gentoo just makes 
this tweaking easier.


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users


Re: [e-users] Gentoo Overlay ebuild issue

2012-08-06 Thread P Purkayastha
On 08/06/2012 11:39 PM, Alan McKinnon wrote:
 On Mon, 06 Aug 2012 23:00:33 +0800
 P Purkayasthappu...@gmail.com  wrote:

 On 08/06/2012 04:45 PM, Carsten Haitzler (The Rasterman) wrote:
 actually both gentoo ebuild users and the tweakers end up on our
 doorstep asking us for help with their tweaked builds. on our
 irc/email lists. though it's nice to help - we help again and again
 and repeat ourselves that those options are for people who know
 exactly what they are doing with the option. if u dont know then
 accept defaults without a --enable or --disable in sight. :) u do
 more than that then deal with your own problems - they never do
 though. we end up with them. so the future is many fewer options.
 u'll be patching src to change things and that tends to be a
 barrier high enough to keep the tweakers out :)


 That's not quite true. At least with *good* ebuilds in current
 Gentoo. *Good* ebuilds themselves provides configure options such
 that the default configure options are sane. For example look at the
 default options for evas:

 ~» eix -e evas
 [I] media-libs/evas
Available versions:  (~)1.0.1 (~)1.1.0 (~)1.2.1
 (**){tbz2}[1] {X altivec bidi +bmp +cache directfb doc +eet fbcon
 +fontconfig gif gles +ico +jpeg mmx nls opengl +png +ppm +psd sdl sse
 sse3 static-libs svg tga +threads tiff xcb xpm}


 You see all the + things? It means that those configure options (USE
 flags in Gentoo terminology) are all enabled by default and the rest
 are disabled by default.

 Hmmm, not quite. Those are the defaults for the ebuild only.

 The user may well have enabled several of those flags system-wide in
 make.conf, such things as mmx, sdl, sse and xcb. In which case they
 will be enabled regardless of what the ebuild says.


Yes, that's true. But only a ricer will go ahead and enable flags that 
are destructive or not useful. If you have an old enough machine, you 
won't enable sse2, but you will probably enable sse and mmx. That makes 
sense. I don't enable sse3 on my make.conf because my cpu doesn't 
support that instruction set. On the other hand I know that my cpu can 
handle sse2 instructions, so I have enabled it. So, now evas, mplayer, 
etc can all make use of this fact.


 Better to look at other stuff in the ebuild, like this:



 src_configure() {
  if use X ; then
  if use xcb ; then
  ewarn You have enabled both 'X' and 'xcb', so
 we will use ewarn X as it's considered the most stable for evas
  fi
  MY_ECONF=
  --disable-software-xcb
  $(use_enable opengl gl-xlib)
  
  elif use xcb ; then
  MY_ECONF=
  --disable-gl-xlib
  --enable-software-xcb
  $(use_enable opengl gl-xcb)
  
  else
  MY_ECONF=
  --disable-gl-xlib
  --disable-software-xcb
  --disable-gl-xcb
  
  fi


This part is clear. If the user enables xcb (the user will have X 
enabled anyway if he selects the desktop profile), then the ebuild will 
default to X instead of xcb. This is actually good! For instance, 
elementary doesn't work with xcb (so, no 'terminology' for you if you 
forcibly disabled X for e and efl!). If the user doesn't have X, then 
the user doesn't want gl or xcb either.



 #   $(use_enable cache metric-cache)
 #   $(use_enable cache word-cache)
  MY_ECONF+=
  --disable-metric-cache
  --disable-word-cache
  $(use_enable altivec cpu-altivec)
  $(use_enable bidi fribidi)
  $(use_enable bmp image-loader-bmp)
  $(use_enable bmp image-loader-wbmp)
  $(use_enable directfb)
  $(use_enable doc)
  $(use_enable eet font-loader-eet)
  $(use_enable eet image-loader-eet)
  $(use_enable fbcon fb)
  $(use_enable fontconfig)
  $(use_enable gles gl-flavor-gles)
  $(use_enable gles gles-variety-sgx)
  $(use_enable gif image-loader-gif)
  $(use_enable ico image-loader-ico)
  $(use_enable jpeg image-loader-jpeg)
  $(use_enable mmx cpu-mmx)
  $(use_enable png image-loader-png)
  $(use_enable ppm image-loader-pmaps)
  $(use_enable psd image-loader-psd)
  $(use_enable sdl software-sdl)
  $(use_enable sse cpu-sse)
  $(use_enable sse3 cpu-sse3)
  $(use_enable svg image-loader-svg)
  $(use_enable tga image-loader-tga)
  $(use_enable tiff image-loader-tiff)
  $(use_enable threads pthreads)
 

Re: [e-users] Gentoo Overlay ebuild issue

2012-08-06 Thread Gustavo Sverzut Barbieri
On Mon, Aug 6, 2012 at 12:00 PM, P Purkayastha ppu...@gmail.com wrote:
 On 08/06/2012 04:45 PM, Carsten Haitzler (The Rasterman) wrote:
 actually both gentoo ebuild users and the tweakers end up on our doorstep
 asking us for help with their tweaked builds. on our irc/email lists. though
 it's nice to help - we help again and again and repeat ourselves that those
 options are for people who know exactly what they are doing with the option. 
 if
 u dont know then accept defaults without a --enable or --disable in sight. 
 :) u
 do more than that then deal with your own problems - they never do though. we
 end up with them. so the future is many fewer options. u'll be patching src 
 to
 change things and that tends to be a barrier high enough to keep the tweakers
 out :)


 That's not quite true. At least with *good* ebuilds in current Gentoo.
 *Good* ebuilds themselves provides configure options such that the
 default configure options are sane. For example look at the default
 options for evas:

 ~» eix -e evas
 [I] media-libs/evas
   Available versions:  (~)1.0.1 (~)1.1.0 (~)1.2.1 (**){tbz2}[1]
 {X altivec bidi +bmp +cache directfb doc +eet fbcon +fontconfig gif gles
 +ico +jpeg mmx nls opengl +png +ppm +psd sdl sse sse3 static-libs svg
 tga +threads tiff xcb xpm}


 You see all the + things? It means that those configure options (USE
 flags in Gentoo terminology) are all enabled by default and the rest are
 disabled by default. This means that if the user is not a ricer, then
 he/she will be compiling evas with just the options that are not likely
 to break evas. If the user is a ricer, he/she will tweak around with all
 the configure flags irrespective of the linux distro. Gentoo just makes
 this tweaking easier.

it's worth to note that Gentoo is the only distro that packages
EFL/E17 in its most updated form. You can emerge directly from SVN and
test the latest code.

Then it's expected that some gentoo users will show with some problems due that.

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users


Re: [e-users] Gentoo Overlay ebuild issue

2012-08-06 Thread Alan McKinnon
Top posting as I'm not really replying to your statements directly.

I do agree with everything you said, and raster and I have had this
good-natured argument about Gentoo before. I don't know if 
the argument was won but it sure wasn't by me :-)

I just wanted to add that for the most part devs out there do a good job of 
writing code and build systems. For the most part ebuild
maintainers do an equally good job of keeping ebuilds straight (we'll
ignore the exceptions, they will always be around).

I use source distros wherever I can - Gentoo and FreeBSD. So I need
clear and explicit ./configure options without automagic dependencies.
I want to tweak software builds to support the things I want to support
in a nice safe manner without being beholden to whatever a binary
distro packager thinks I should have (I'm old school in that regard and
not likely to change...)

Maybe the things I want are at odds with most of the rest of the
planet. e17 is well-behaved when it comes to being built, but sadly not
everything else out there has the same quality levels. If you use
Gentoo, you likely know how much automagic build crazy is in the world
(and why it is an evil that must be driven from the world and burnt to
a cinder)



On Tue, 07 Aug 2012 00:08:06 +0800
P Purkayastha ppu...@gmail.com wrote:

 On 08/06/2012 11:39 PM, Alan McKinnon wrote:
  On Mon, 06 Aug 2012 23:00:33 +0800
  P Purkayasthappu...@gmail.com  wrote:
 
  On 08/06/2012 04:45 PM, Carsten Haitzler (The Rasterman) wrote:
  actually both gentoo ebuild users and the tweakers end up on our
  doorstep asking us for help with their tweaked builds. on our
  irc/email lists. though it's nice to help - we help again and
  again and repeat ourselves that those options are for people who
  know exactly what they are doing with the option. if u dont know
  then accept defaults without a --enable or --disable in sight. :)
  u do more than that then deal with your own problems - they never
  do though. we end up with them. so the future is many fewer
  options. u'll be patching src to change things and that tends to
  be a barrier high enough to keep the tweakers out :)
 
 
  That's not quite true. At least with *good* ebuilds in current
  Gentoo. *Good* ebuilds themselves provides configure options such
  that the default configure options are sane. For example look at
  the default options for evas:
 
  ~» eix -e evas
  [I] media-libs/evas
 Available versions:  (~)1.0.1 (~)1.1.0 (~)1.2.1
  (**){tbz2}[1] {X altivec bidi +bmp +cache directfb doc +eet
  fbcon +fontconfig gif gles +ico +jpeg mmx nls opengl +png +ppm
  +psd sdl sse sse3 static-libs svg tga +threads tiff xcb xpm}
 
 
  You see all the + things? It means that those configure options
  (USE flags in Gentoo terminology) are all enabled by default and
  the rest are disabled by default.
 
  Hmmm, not quite. Those are the defaults for the ebuild only.
 
  The user may well have enabled several of those flags system-wide in
  make.conf, such things as mmx, sdl, sse and xcb. In which case they
  will be enabled regardless of what the ebuild says.
 
 
 Yes, that's true. But only a ricer will go ahead and enable flags
 that are destructive or not useful. If you have an old enough
 machine, you won't enable sse2, but you will probably enable sse and
 mmx. That makes sense. I don't enable sse3 on my make.conf because my
 cpu doesn't support that instruction set. On the other hand I know
 that my cpu can handle sse2 instructions, so I have enabled it. So,
 now evas, mplayer, etc can all make use of this fact.
 
 
  Better to look at other stuff in the ebuild, like this:
 
 
 
  src_configure() {
   if use X ; then
   if use xcb ; then
   ewarn You have enabled both 'X' and
  'xcb', so we will use ewarn X as it's considered the most stable
  for evas fi
   MY_ECONF=
   --disable-software-xcb
   $(use_enable opengl gl-xlib)
   
   elif use xcb ; then
   MY_ECONF=
   --disable-gl-xlib
   --enable-software-xcb
   $(use_enable opengl gl-xcb)
   
   else
   MY_ECONF=
   --disable-gl-xlib
   --disable-software-xcb
   --disable-gl-xcb
   
   fi
 
 
 This part is clear. If the user enables xcb (the user will have X 
 enabled anyway if he selects the desktop profile), then the ebuild
 will default to X instead of xcb. This is actually good! For
 instance, elementary doesn't work with xcb (so, no 'terminology' for
 you if you forcibly disabled X for e and efl!). If the user doesn't
 have X, then the user doesn't want gl or xcb either.
 
 
 
  #   $(use_enable cache metric-cache)
  #   $(use_enable cache word-cache)
   

Re: [e-users] Gentoo Overlay ebuild issue

2012-08-06 Thread The Rasterman
On Mon, 6 Aug 2012 23:45:25 +0200 Alan McKinnon alan.mckin...@gmail.com said:

 Top posting as I'm not really replying to your statements directly.
 
 I do agree with everything you said, and raster and I have had this
 good-natured argument about Gentoo before. I don't know if 
 the argument was won but it sure wasn't by me :-)
 
 I just wanted to add that for the most part devs out there do a good job of
 writing code and build systems. For the most part ebuild maintainers do an
 equally good job of keeping ebuilds straight (we'll ignore the exceptions,
 they will always be around).
 
 I use source distros wherever I can - Gentoo and FreeBSD. So I need
 clear and explicit ./configure options without automagic dependencies.
 I want to tweak software builds to support the things I want to support
 in a nice safe manner without being beholden to whatever a binary
 distro packager thinks I should have (I'm old school in that regard and
 not likely to change...)
 
 Maybe the things I want are at odds with most of the rest of the
 planet. e17 is well-behaved when it comes to being built, but sadly not
 everything else out there has the same quality levels. If you use
 Gentoo, you likely know how much automagic build crazy is in the world
 (and why it is an evil that must be driven from the world and burnt to
 a cinder)

efl generally is well behaved.. except it is rather automagic. if u --enable
something that has a dependency - and the dep is not found... the feature is
disabled again (configure output tells you so at the end). some people want
configure to fail in this case. ours do not - they march on and adjust config
to match the environment they found. but you are right many of those options
make me CRINGE.

main if sections at the top:

1. xcb as an option at all. we have the support, but the problem is its not
100% complete and working. its like 98%. some key things will not work with xcb
and people end up complaining to us. we know this, and that is why its not on
by default. you don't have to --disable the xcb support - it's off by default.
2. the xcb options... kill gl - this is a fine and nasty detail where we CANNOT
have gl support without SOME minimal xlib support. everything else except for
some minimal opengl interaction is xcb, but when interfacing to glx/egl itself
we use xlib. i advise that you DONT disable gl-xlib as you lose major
functionality.
3. word and metric caching are off by default anyway - so no need to disable.
the day these things are stable and ready for use we'll enable them by default.

other use_enable flags:

4. altivec - if u are on a ppc chip.. then why NOT enable altivec? pointless to
make it an option - it's detected at runtime if u don't have the instructions.
5. bidi - why just fribdi - harfbuzz is also involved in bidi support.
6. directfb - it's off by default... for a good reason. it's not maintained
anymore.
7. doc - ummm ok, though docs are not BUILT unless you do make doc so i dont
see a point of swizzling this here
8. eet - this shouldnt be an option. the rest of efl wont work without it. it's
pointless making it an option as no one anywhere uses evas by itself RAW. in
fact there are no docs on how to do it and the only people who really know
how... are us (pretty much), so it's pretty pointless being an option. we were
totally anal in making it an option to avoid people patching our builds for the
rare case of some hyper-embedded environment where this may be the case (it'
also a leftover from making evas toolkit agnostic thinking maybe the gnome and
kde crowds wouldn't pull an NIH and go make their own scene graph canvases -
but as is normal they did this again, so this is the last time we try and
bother being agnostic - we're ditching the be nice to other toolkits mantle
becuase it costs us work/effort for no gain as they don't care... not invented
here.
9. fbcon - why an option? it just needs some linux fb dev headers and that's it.
no other deps. its a module file that isnt even used unless called for at
runtime?
10. fontconfig ... boundary case - but frankly nothing on top of evas
(elementary, e17) runs right unless you have fontconfig and sans fonts etc. so
i'd highly discourage this ever being turned off (except for very very very
niche cases).
11. gles - fair enough
12. gif - very useful, small dep. i'd discourage this being turned off
13. ico - no deps, just a module. useful. dont turn it off
14. jpeg - small dep. essential
15. mmx - like altivec. keep it on. runtime figures it out.
16. png - like jpeg - small dep, essential
17. ppm - no dep, useful
18. psd - no dep, useful
19. sdl - fair enough
20. sse - like altivec
21. sse3 - small catch - needs more modern gcc with sse3 intrinsics support, so
ok. fair enough
22. svg - fair enough - needs esvg/enesim now... big dep chain
23. tga - no dep, useful
24. tiff - small dep, useful
25. threads - enable or disable of pthreads is a bad idea. ultra-embedded or
windows support atm needs this off, but 

Re: [e-users] Gentoo Overlay ebuild issue

2012-08-06 Thread Cedric BAIL
On Tue, Aug 7, 2012 at 9:57 AM, Carsten Haitzler ras...@rasterman.com wrote:
 3. word and metric caching are off by default anyway - so no need to disable.
 the day these things are stable and ready for use we'll enable them by 
 default.

I removed that one as it was not maintained and didn't bring any more
performance since the change Tom did on the font system with
Evas_Text_Props. So this option are dead in svn since at least 2
months.
-- 
Cedric BAIL

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users


Re: [e-users] Gentoo Overlay ebuild issue

2012-08-06 Thread Wido


On Monday August 6 2012 07:38:03 Carsten Haitzler escribió:
 On Mon, 6 Aug 2012 12:18:56 +0200 Alan McKinnon alan.mckin...@gmail.com 
 said:
 
  On Mon, 6 Aug 2012 17:45:36 +0900
  Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote:
  
   actually both gentoo ebuild users and the tweakers end up on our
   doorstep asking us for help with their tweaked builds. on our
   irc/email lists.
  
  
  We call those people ricers
  
  Maybe you should follow our lead on the gentoo user lists - we help out
  ricers as and when we feel like it but mostly just tell them to put
  everything back to stock and observe how stuff now works.
  
  Myself, I've been using e17 on gentoo for 6 years or more and I've
  used all 3 well-known overlays. Never had a problem with them yet worth
  mentioning.
 
 time to make this a rice free zone! :)

I like my chop suey, you insensitive clod! ( slashdot-dixit :P )

 
 
-- 

--
Wido

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users


Re: [e-users] Gentoo Overlay ebuild issue

2012-08-06 Thread The Rasterman
On Tue, 7 Aug 2012 11:17:44 +0900 Cedric BAIL cedric.b...@free.fr said:

 On Tue, Aug 7, 2012 at 9:57 AM, Carsten Haitzler ras...@rasterman.com wrote:
  3. word and metric caching are off by default anyway - so no need to
  disable. the day these things are stable and ready for use we'll enable
  them by default.
 
 I removed that one as it was not maintained and didn't bring any more
 performance since the change Tom did on the font system with
 Evas_Text_Props. So this option are dead in svn since at least 2
 months.

configure.ac still has the word and metric cache stuff in it tho... u should
remove that too. :)

-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users


Re: [e-users] Gentoo Overlay ebuild issue

2012-08-06 Thread The Rasterman
On Mon, 6 Aug 2012 23:31:49 -0300 Wido wido...@gmail.com said:

 
 
 On Monday August 6 2012 07:38:03 Carsten Haitzler escribió:
  On Mon, 6 Aug 2012 12:18:56 +0200 Alan McKinnon alan.mckin...@gmail.com
  said:
  
   On Mon, 6 Aug 2012 17:45:36 +0900
   Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote:
   
actually both gentoo ebuild users and the tweakers end up on our
doorstep asking us for help with their tweaked builds. on our
irc/email lists.
   
   
   We call those people ricers
   
   Maybe you should follow our lead on the gentoo user lists - we help out
   ricers as and when we feel like it but mostly just tell them to put
   everything back to stock and observe how stuff now works.
   
   Myself, I've been using e17 on gentoo for 6 years or more and I've
   used all 3 well-known overlays. Never had a problem with them yet worth
   mentioning.
  
  time to make this a rice free zone! :)
 
 I like my chop suey, you insensitive clod! ( slashdot-dixit :P )

funroll-loops. :)

-- 
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users


Re: [e-users] Gentoo Overlay ebuild issue

2012-08-05 Thread Mick
On Sunday 05 Aug 2012 18:52:36 SndChaser wrote:
 Forgot to add,
 
 I've paste-binnned build logs, environment logs, etc here:
 
 http://pastebin.sabayon.org/pastie/10173
 http://pastebin.sabayon.org/pastie/10174
 http://pastebin.sabayon.org/pastie/10175


Hi George,

Since this is a Gentoo specific bug you should send a message to 
enlightenm...@gentoo.org and a dev will look into it.

-- 
Regards,
Mick
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users


Re: [e-users] Gentoo Overlay ebuild issue

2012-08-05 Thread SndChaser
Thanks Nick,

I've forwarded my messages to the gentoo address.

George

On 2012-08-05 13:38, Mick wrote:
 On Sunday 05 Aug 2012 18:52:36 SndChaser wrote:
 Forgot to add,

 I've paste-binnned build logs, environment logs, etc here:

 http://pastebin.sabayon.org/pastie/10173
 http://pastebin.sabayon.org/pastie/10174
 http://pastebin.sabayon.org/pastie/10175


 Hi George,

 Since this is a Gentoo specific bug you should send a message to
 enlightenm...@gentoo.org and a dev will look into it.

-- 
We need to heed the words of the Dalai Lama,
Or at least, the words of your mama.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users