On Saturday 28 February 2009 09:54:00 Joe(theWordy)Philbrook wrote:
> It would appear that on Feb 27, Alan McKinnon did say:
> > Look in /etc/layman/layman.cfg and find the "storage" directive. You will
> > find your layman overlays inside that directory. It's not necessarily set
> > to /usr/portage/local/layman/ (and might even default to below $PORTDIR
> > at install time)
>
> Am I glad to be talking with you! Perhaps I can even do this without
> borking another install... ;-7
>
> You helped me find the actual currently in use location where (thank
> God!) the overlay (with the scripts) does exist...
>
> On the test installation of Sabayon where I'm doing this I've already
> emerged "enlightenment" without the keywords in place. I have not yet
> tried to emerge eine, eet, etc... Should I perhaps be best off getting
> the keywords file in place and then running:
>
> emerge --newuse enlightenment
>
> Before I install anything else???
That will work fine the first time, as enlightenment has all the EFL libs as
dependencies, and they in turn have their own dependencies, so they will all
be pulled in correctly, including eina, eet, evas, etc
The next time you run 'emerge enlightenment' it will build only the window
manager, not the EFL as well. The reason is that the EFL may have changed but
portage has no way to know that. It normally decides if it should rebuild some
dependency by looking at version numbers, but the e17 svn ebuilds all have
version 9999 and it never changes. The only reliable solution is to rebuild
everything every time you update. It takes about 90 minutes on a decent modern
machine.
I used to have a convoluted script thingy that listed every e17 app and lib
and emerged them all. Now with portage sets I just stick everything in the set
and 'emerge @e17'. It also keep my world file uncluttered.
> > Please don't believe anything you read at gentoo-wiki.com, it is
> > hopelessly outdated, was entirely lost a good while back and has been
> > regenerated from search engine caches. It's uncertain whether that page
> > is relevant anymore. The correct reference is from the maintainer of the
> > overlay:
> >
> > http://overlays.gentoo.org/dev/vapier/wiki/enlightenment
>
> Thank you, Site is now bookmarked!
>
> Ummnnn. I noticed two things.
>
> 1) he says to: "emerge e"... But on my laptop where I've added the
> overlay (but emerged no part of e yet) I just did an "emerge --ask e"
> to see what it offered. "no ebuilds" As far as I can see the only E it
> wants to give me is x11-wm/enlightenment 0.16.8.15 (says I've got
> 0.16.8.11 Which must be e16... is 0.16.8.15 correct for E17??? And if
> I do the emerge on that laptop won't I lose e16?? (I like to switch
> off...) On my desktop I've enough hard drive space to run two copies
> of Sabayon if need be to have both e16 and e17 available...
Ah. That's because vapier changed the name of the ebuild from 'e' to
'enlightenment'. They should also be slotted so e16 and e17 do not clobber
each other when portage figures out what to build.
version 0.16.8.15 is the current release of e16
You might find versions 0.16.9999 in various places, that will probably be e17
which is of course an entirely different thing altogether and merely shares a
common name. You can easily run a recent e16 and e17 on the same machine (just
like gnome and kde can co-exist) becuase all the files have different names
> 2) He mentions "export E17_WANT_AUTOMAKE=1.9"...
> Ummnn I just did an "emerge --search automake" it's only offering
> 1.10.1 & 1.10.2... Is setting this environmental variable still
> going to help?
I haven't used that hack for ages. There was a time when it was needed as not
all the e17 code had been fixed to use recent autotools. Obviously the
intention is to gradually fix everything so hacks are not needed. This may
even have happened by now. All I know is that I don't do anything variable
hacking to get stuff to build.
Perhaps someone else more familiar with the code itself could comment on if
this hack is still needed.
> > What you really want to do is:
> >
> > emerge layman
> > layman -L
> > layman -a enlightenment
> >
> > The current location of vapier's sample package.keywords is in scripts/
> > inside the overlay directory. You don't need his though, so to help you
> > out I've attached a working one.
>
> Thank you! But now that you've helped me find the script I'll use
> Vapier's recommended symlink. After all if the overlay gets updated with
> updated use flags in the updated included script of the same pathname,
> I'd get the updated keywords automatically. Right?
Correct. vapier also supplies int he overlay the scripts he uses to build the
keywords file. It's quite simple - it finds ebuild names, mangles the name
into shape and spits out a list which you store on disk. If you manage to
damage it, just rerun the script
> There is one thing. I found several sites with instructions to set up an
> /etc/portage/package.keywords/ directory for the symlink
> /etc/portage/package.keywords/enlightenment
> But I only found one site (forgot to bookmark it <sigh>) which told me
> what to do with the original file that was:
> /etc/portage/package.keywords
> If I remember right that site said to move it to:
> /etc/portage/package.keywords/main
>
> I hope that's correct as that IS what I did with it. "???????????????"
That's a portage thing, the man pages describe it nicely. In summary:
You can have a single file like /etc/portage/package.use if you want. This is
hard for ebuilds to work with as to modify it, they have to read the whole
thing, and change just the correct bits whithout changing anything else. Is
this is just way too much work. So, some bright spark had the idea to make
/etc/portage/package.keywords a directory and portage just reads every file in
there and the file names are totally unimportant. Now ebuilds can copy move
and delete their own files at will without affecting anything else.
The choice is yours as to which you want, but the directory approach is so
much better. It looks to me like what you did is fine and will work correctly
>
> > Finally, building e17 on gentoo and derivatives is infinitely easier with
> > sets. emerge a recent *unstable* portage then find the thread from
> > yesterday with subject "Ecore & Enlightenment compile failure" where I
> > gave full details plus working sets files.
>
> Ummnn yeah, I read somewhere that the sets feature is only available in
> portage versions >=2.2 And on my Sabayon the highest available portage
> version (according to "emerge --search portage") is 2.1.6.7 <sigh>
> I'm thinking that the closest to "sets" that I can do here is a
> /root/bin script containing something like the 'for x in $list'
> command suggested on that gentoo wiki you advised against... Did they at
> least get the correct emerge order right???
Hmm, tricky one. I remember having trouble with eina when it was released
(it's the newest of the EFL libs) and deciding to just do it myself. The e17
wiki is quite reliable as to documenting build order. Everything else is not,
including vapiers wiki (he's a busy man, doesn't always get to everything
timeously).
You could always grab a recent portage ebuild, copy it to your local overlay
and emerge it. It's been completely reliable for me, the last time portage
broke something on any of my machine was in 2005 :-)
Let me know if you haven't read up yet on local overlays and need some
pointers.
> I'm thinking:
>
> #!/bin/bash
> export E17_WANT_AUTOMAKE=1.9 #if needed
> list="eina eet evas ecore efreet embryo edje e_dbus enlightenment"
> for x in $list ; do emerge $x ; done
That looks fine to me, nothing strikes me as missing
> I tried to google for "Ecore & Enlightenment compile failure" And I
> got LOTS of stuff But I didn't find the thread itself. <sigh>
> Don't suppose you have the actual url?
It's easier to paste the mail from my sent folder than to look for a URL :-)
I've add it to the bottom, with attachments
> In any case Alan, I thank you for the help you've already so kindly
> given. And I THANK you for the additional info I'm hoping you'll be
> kind enough to tell me.
>
> Have yourself a great day!
Here's the relevant bit from my mail to Cedric:
I find that build failures in EFL are invariably fixed within a day or so, or
I tried to do something stupid, like just build one or two. The proven way is
to rebuild the whole lot in the correct order. The easiest way is with sets -
copy my attached set files to /etc/portage/sets and run 'emerge -av @e17'.
Portage figures out the build order and does it - works every time.
If this still doesn't work for you, you'll need to supply the usual gentoo
debugging stuff - use flags in use, emerge --info, your arch, etc.
--
alan dot mckinnon at gmail dot com
dev-db/edb
media-libs/imlib2
media-libs/imlib2_loaders
media-gfx/imlib2_tools
dev-libs/eina
dev-libs/eet
x11-libs/evas
x11-libs/e_dbus
x11-libs/ecore
dev-libs/efreet
dev-libs/embryo
media-libs/edje
media-libs/epsilon
x11-libs/esmart
media-libs/emotion
x11-libs/etk
x11-libs/ewl
dev-libs/exml
dev-util/enhance
@e17-libs
@e17-apps
@e17-modules
@e17-odds
# The names say it all. For one or other reason, these just don't build
#...@e17-broken
#...@e17-lost
#...@e17-other
x11-plugins/e_modules-alarm
x11-plugins/e_modules-bling
x11-plugins/e_modules-calendar
x11-plugins/e_modules-cpu
x11-plugins/e_modules-deskshow
x11-plugins/e_modules-diskio
x11-plugins/e_modules-efm_nav
x11-plugins/e_modules-efm_path
x11-plugins/e_modules-emu
x11-plugins/e_modules-execwatch
x11-plugins/e_modules-flame
x11-plugins/e_modules-forecasts
x11-plugins/e_modules-iiirk
x11-plugins/e_modules-language
x11-plugins/e_modules-mail
x11-plugins/e_modules-mem
x11-plugins/e_modules-moon
x11-plugins/e_modules-mpdule
x11-plugins/e_modules-net
x11-plugins/e_modules-news
x11-plugins/e_modules-notification
x11-plugins/e_modules-penguins
x11-plugins/e_modules-photo
x11-plugins/e_modules-rain
x11-plugins/e_modules-screenshot
x11-plugins/e_modules-slideshow
x11-plugins/e_modules-snow
x11-plugins/e_modules-taskbar
x11-plugins/e_modules-tclock
x11-plugins/e_modules-tiling
x11-plugins/e_modules-uptime
x11-plugins/e_modules-weather
x11-plugins/e_modules-winselector
x11-plugins/e_modules-wlan
x11-plugins/itask-ng
x11-plugins/winlist_ng
x11-plugins/e_modules
x11-wm/enlightenment
x11-misc/entrance
dev-util/edje_viewer
dev-util/edje_editor
media-gfx/elicit
media-gfx/exquisite
media-sound/emphasis
app-admin/empower
x11-misc/emprint
media-gfx/ephoto
x11-misc/estickies
x11-misc/expedite
media-sound/extrackt
media-video/rage
media-gfx/scrot
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
