2. Dont use enlightenment-9999. The dependencies are broken. The 9999 should be compiled against the merged efl tree iirc. And there is no ebuild to get the merged efl tree._________________emerge --quiet redefined | E17 vids: I, II | Now using e from git | e18, e19, and kde4 sucks :-/

But how can I do this? eix shows me the overlay's versions. Do I have do remove all stuff, including overlay and re-install E17 from portage or there is another way? And what about the package.use and package.keywords folders? With a portage's install there have no use anymore.

But how can I do this? eix shows me the overlay's versions. Do I have do remove all stuff, including overlay and re-install E17 from portage or there is another way? And what about the package.use and package.keywords folders? With a portage's install there have no use anymore.

Actually, yes, that would be the best way. Remove it all, remove the overlay, then pull from portage. The .use and .keywords shouldn't be required - unless, of course, you want specific use flags._________________the Silly Fish.

I can see that -access and -shot are set by default, how to "disable" other things as well?_________________"Nolite arbitrari quia venerim mittere pacem in terram non veni pacem mittere sed gladium" (Yeshua Ha Mashiach)

I am quite enjoying this new version. The file manager is pretty solid (I still miss hierarchy view for folders, and I will probably miss forever the feature that only konqueror has: the unlimited split view) and I might be using it for simple issues.

Now, something that annoys me a bit is the everything module. I hear wonders about it, but honestly, I never get the grip. Perhaps I'm too used to gmrun and its amazing tab autocompletion, but since gmrun is no longer maintained I'm starting to get anxious about it... I'll keep trying to give everything module a try, but gah!

Now, something that annoys me a bit is the everything module. I hear wonders about it, but honestly, I never get the grip. Perhaps I'm too used to gmrun and its amazing tab autocompletion, but since gmrun is no longer maintained I'm starting to get anxious about it... I'll keep trying to give everything module a try, but gah!

The everything module takes some time to gather statistics. tab completion won't work (or maybe it does and I don't know the shortcut). The way to use it is to start typing any program name and if the program comes up in the list below, then you can press enter without completing the name. Same holds for
enlightenment settings (start typing "keybind" to see the keybinding setting, etc),
calculator (start with =, needs bc to be installed),
windows (start typing window name that is already open),
files (start typing file/directory name in the home directory, or start giving full path by starting to type with "/", or if you have the everything-places module then it can show files/directories that are in your gtk-bookmarks),
wikipedia, youtube, google search, etc. can be also searched by installing some extra plugins._________________emerge --quiet redefined | E17 vids: I, II | Now using e from git | e18, e19, and kde4 sucks :-/

Yes. e_modules-mail from enlightenment overlay. It should work with e-0.17.0. Just make sure to keyword ** only this particular ebuild._________________emerge --quiet redefined | E17 vids: I, II | Now using e from git | e18, e19, and kde4 sucks :-/

Yes. e_modules-mail from enlightenment overlay. It should work with e-0.17.0. Just make sure to keyword ** only this particular ebuild.

It seems not to work. Or I do not know how it should work. I have tried imap on a local dovecot server and local maildir. With imap I get 0/0 mails, with maildir 0/<number of current mails> although there are unread mails.

It seems not to work. Or I do not know how it should work. I have tried imap on a local dovecot server and local maildir. With imap I get 0/0 mails, with maildir 0/<number of current mails> although there are unread mails.

Is there a log file that may give me some clue why it does not work?

No idea. Like I mentioned several posts above, I don't use it.

@ulenrich: enlightenment is slotted in Gentoo. slot 0 is e16, slot 0.17 is e17. That's how slots work. Nothing wrong with that. It is unfortunate that the version number of e16 is set to 1.0.x by upstream._________________emerge --quiet redefined | E17 vids: I, II | Now using e from git | e18, e19, and kde4 sucks :-/

It seems not to work. Or I do not know how it should work. I have tried imap on a local dovecot server and local maildir. With imap I get 0/0 mails, with maildir 0/<number of current mails> although there are unread mails.

Is there a log file that may give me some clue why it does not work?

No idea. Like I mentioned several posts above, I don't use it.

@ulenrich: enlightenment is slotted in Gentoo. slot 0 is e16, slot 0.17 is e17. That's how slots work. Nothing wrong with that. It is unfortunate that the version number of e16 is set to 1.0.x by upstream.

Uuups, now I am really confused: I thought of E17 released by upstream as of
Enlightenment17-v1
???_________________fun2gen2

What about ecomp/ecomorph? Are we going to have an upstream version of those also? Is the 9999 still working and/or is safe to use it? I've noticed that there is a compositing embedded, but it is not the same thing as ecomorph..._________________"Nolite arbitrari quia venerim mittere pacem in terram non veni pacem mittere sed gladium" (Yeshua Ha Mashiach)

What about ecomp/ecomorph? Are we going to have an upstream version of those also? Is the 9999 still working and/or is safe to use it? I've noticed that there is a compositing embedded, but it is not the same thing as ecomorph...

ecomp/ecomorph is not upstream - it is a port of the compiz code from around 2007 to work with e17. As such, I don't know if it is maintained nowadays.

As for enlightenment-9999, I would suggest you to not use it unless you are adventurous. The svn is undergoing lots of changes, including the merge of several efl libraries into one single library/build process. The svn version of e depends on this single build process. Last I checked, the ebuilds do not support this monolithic trunk/efl directory. I didn't even see an efl-9999 ebuild. Stick to stable e for the time being if e is your primary desktop._________________emerge --quiet redefined | E17 vids: I, II | Now using e from git | e18, e19, and kde4 sucks :-/

ecomp/ecomorph is not upstream - it is a port of the compiz code from around 2007 to work with e17. As such, I don't know if it is maintained nowadays.

As for enlightenment-9999, I would suggest you to not use it unless you are adventurous. The svn is undergoing lots of changes, including the merge of several efl libraries into one single library/build process. The svn version of e depends on this single build process. Last I checked, the ebuilds do not support this monolithic trunk/efl directory. I didn't even see an efl-9999 ebuild. Stick to stable e for the time being if e is your primary desktop.

Hrm... this probably could warrant a topic of its own, but I'll ask here first.

For quite some time, I've had e17 on my little—test—laptop, working fine and great, but (I think) after this landed into Portage, it stopped working on this main machine. I had not used it for a while, so I'm unsure if the change from overlay to Portage is when it started happening.

Anyblue, to the point!

Starting e would lead into a SIGABRT. More specifically, if starting with a clean prefix, so to speak, I could set the preferences for language and such. When all that is done, it would crash at the point where it should load up the actual desktop. I would get the crash saying SIGABRT'd, which shouldn't happen, and that we couldn't get a backtrace. There would be notes about enabling debugging CFLAGS for e and EFL, and I did just that: CFLAGS="-O0 -g -ggdb3 -pipe". This made no difference (also used the debug USE flag for the packages that have it). Perhaps I should have tried manually compiling it from source, though I'm thinking it shouldn't be required in this case.

So, today, I tried with an old test user account to see if it SIGABRTs on that, too. It didn't, so then I went into comparing them logs and this caught my eye(s):

Code:

MODULE ERR:
There was an error loading the module named: shot<br>No module named shot/linux-gnu-x86_64-0.17.1/module.so could be found in the<br>module search directories.<br>

Now, the question here is, why isn't this module even mentioned in the log for the test user's account? What's pulling it in at run-time, but not at build-time?

I enabled the mentioned module which was one of the two disabled by default ones (the other being access), and now it seems to work. It's crashing a lot when loading settings and other dialogues, but I imagine that might be due to having KDE running at the same time for the same user? Have to test later with no KDE up.

So questions:

Why are we unable to get a backtrace? I did not try to manually attach to the process yet. Have to look into that with more time.

Why is shot required for the main user but not for the test (almost clean) user?

Does it seem like a bug in dependencies?

While it does seem to more or less work now, I posted because I could find no information about this specific issue after lots of DuckDuckGoing and whatnots, so as to document it somewhere for future reference. That, and I would like to understand why it happened to me in the first place. ^^

Might really be a better idea to create a topic of its own for this, unless there's something really simple someone knows to point out!

I feel like I forgot some things, but I think that's the gist of it. Gotta find some sleep now..._________________Kind Regards,
~ The Noob Unlimited ~

shot is a module. If you don't build it, e will fail to load it, but e will run just fine. I have e-0.17.1 running here just fine and I have some modules like connman disabled at build time. It looks like a problem very specific to your setup. Probably you have some old e17 libraries lying around?

Does USE="debug" also change CFALGS?
IMHO it just enables debug build which adds some nasty asserts plus some extra console output - but NOT "-g -ggdb" to CFLAGS.
And (according to man make.conf) FEATURES="splitdebug" does not do any extra work - only "splits debug info" away.

And (according to man make.conf) FEATURES="splitdebug" does not do any extra work - only "splits debug info" away.

It is true. After you are done debugging you can delete the debug files from /usr/lib/debug._________________emerge --quiet redefined | E17 vids: I, II | Now using e from git | e18, e19, and kde4 sucks :-/

shot is a module. If you don't build it, e will fail to load it, but e will run just fine. I have e-0.17.1 running here just fine and I have some modules like connman disabled at build time. It looks like a problem very specific to your setup. Probably you have some old e17 libraries lying around?

Yeah, I imagined it should be very much optional. I do find it very strange that e17 will not even start without it for the specific user.

I think it came to me only a few minutes after posting that it almost definitely has to be leftover crud from the old tests, from overlays etc., that is causing this. I will have to look everywhere e17 stores things (so far I only know of ~/.e and ~/.cache and both of those I have obliterated between tests). I'm also not sure why I imagined that KDE running on the same user at the same time could affect parts of e17. I was probably remembering way back to when KDE things might behave strangely when run from KDE and e17 both, heh... Wow, that was ages ago! It was like when e17 was still coming.

The last test I ran only e17 and it would crash all the time when trying to load system settings or anything really.

I believe I used the Gentoo Backtraces xml for directions on this waaay back, except I recently changed the -ggdb to -ggdb3 since that's what the e17 message mentions.

Anywho, I'm quite certain the problem for the crashing indeed is some leftovers somewhere in the user's home. Not getting the backtrace will probably bug me to no end, so I'll have to get down on that as well. Sooo thanks for them suggestions! Will try them out soon._________________Kind Regards,
~ The Noob Unlimited ~