LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   how-to: e17 from trunk (https://www.linuxquestions.org/questions/slackware-14/how-to-e17-from-trunk-887557/)

abrouwers 06-21-2011 09:50 AM

how-to: e17 from trunk
 
Hi!

For the past couple of months, I have been using (and enjoying) e17. It's really slick, and has some nice little visual perks while being pretty light-weight. A very nice balance between simple window managers and full-blown desktop environments.

Recently, the enlightenment libraries were released as 1.0.x, as a stable release. These are available on SBo, and work really well! However, most of the action for e17 actually exists in SVN still, which is quick paced and even more feature-full than the released items:

http://trac.enlightenment.org/e/timeline

Many people actually run trunk regularly, as it is very stable, and rarely breaks. I've had similar results, and came up with a nice way to keep up-to-date with packages:

http://www.slackadelic.com/~thrice/e17/

The README contains the details, but it's basically a script to generate some tarballs, and then a single script to run through and build + upgrade/install the packages.

I've been using this for a couple months with pretty good success, so thought I would share :-) Comments, feedback, and hate mail welcome. Or, if you just want to check out e17, it's a quick and easy way to give it a shot.

sahko 06-21-2011 04:26 PM

Thanks! I started using e17 yesterday on Slackware using the 1.0.1 stable release.
Its a really nice window manager and what surprised me is that its even more complete as an environment than XFCE, yet people call XFCE a desktop environment and e a window manager.
Weird.
Big bonus for e is that it manages to stay away from the freedesktop (aka GNOME aka Red Hat) technologies such as the *kits and all that crap while not missing anything in terms of usability or completeness in compare to any of the DE's.
Additionally connman which is a really simple connection manager is intergrated to it so theres absolutely no need for wicd or networkmanager.
Personally i have a great deal of trouble getting used to the way it works, especially the settings dialogues, but i mostrly attribute that to the years of excessive ratpoison usage.
I also didn't like much the way the settings are stored at $HOME from a first glance.
IMO e makes sense including in a distribution like Slackware far far far far more than KDE or XFCE. Hopefully more people will try it now that you are hosting the scripts all together. IMO e proves the complexity in the Linux DE's is absolutely uneeded.

PS. You should probably include connman too. :)

abrouwers 06-21-2011 05:07 PM

Cool, glad it works :) I use connman too:

https://github.com/abrouwers/ajb_sla...master/connman

It seems to mostly work OK, though the client could use some love (which is on the to-do list for the E guys), but does the job well enough for my needs.

sahko 06-22-2011 01:30 PM

I will probably try your scripts within the next few days just to check out whats going on in SVN too, and possibly provide some feedback.

gargamel 06-26-2011 11:29 AM

Thanks, abrouwers!

Recently I saw Enlightenment DR17 on SBo, and tried it. I have to say, that I find it really appealing. Then I saw your post here, and tried that, too. Thanks for sharing your work!

In general, everything seems ok, but there are a few "snags" I am struggling with.

Font size too small
The default font size is a bit small. I found the font size settings dialog and tried to change it, but my settings are ignored, even after restarting e17.

System keyboard settings not honoured
When I log on to e17, I have a US keyboard layout, but when I installed my system I set it to German -nodeadkeys. This works with no change in some other environments, such as KDE, and I even can change it for that DE and the logged in user only, there, without spoiling the system wide setting. But in e17 (and Xfce, BTW) the system setting is apparently ignored, which is not what I'd expect when I choose "Use system default" (in Xfce, don't remember, what it's called like exactly in e17, at the moment).
Now, I was able to change to a German keyboard layout, but had to select a keyboard for this. My keyboard wasn't offered, so I looked for something "compatible" with Logitech Wave, and chose Microsoft Natural Pro OEM.

Unusual arrow key bindings
Not sure, if this is related to the above, but e17 seems to use uncommon arrow key bindings. E. g., when I type in an URL in a web browser, such as Seamonkey, the browser presents me with a list of previously used URLs as a list that is narrowed down as I type. Instead of typing the full URL, I can just use the Arrow-Down and Up key to navigate downwards and upwards in the list and to press the enter key to select an entry from the list, in order to enter that URL. It's harder to describe than to do it, but I guess you know, what I mean.
Not so in e17. The Arrow Down seems to be dead, and the Up key opens a dialog for taking a screenshot, which is useless in most situations and very uncommon. Instead of the arrow keys, the numeric keys 2, 4, 6 and 8 are used to navigate.
Although I found the dialog, where I can change key bindings, I was unable to find a simple way to set this to a more common, not to say "standard", behaviour.

Empty applications menu
When I first installed e17 from SBo, I had a menu with all the familiar entries for applications from KDE and Xfce etc. As I screwed my e17 installation by tweaking it too much, I deleted my .e directory, then logged off and in again. Now the menu entry for applications is empty. I tried to switch between the menu type settings (Enlightenment or Kmenuedit), but this had no visible effect.

But as I said: I find e17 really nice, I like the eye candy, and it's generally stable, as it seems. For me it's going to be *the* alternative to KDE, provided, that I find solutions for the issues mentioned above. Any helpful hints much appreciated!

IMPORTANT: I am by no means trying to hijack this thread. I just post here, because I am on Slackware64-13.37 multilib and use your scripts for e17 from trunk, and therefore hope to find some more experienced users here. But if you prefer, I'll open a new thread, of course.

Thanks again!

gargamel

gargamel 06-26-2011 12:31 PM

Back on topic:

I've just checked out everything from trunk and ran into a version numbering problem. I was able to resolve it for ecore, but for enlightenment, I don't get around it, so far.

After compiling and installing all other components I did:

Code:

# sh e17.SlackBuild enlightenment
And this is, what I get:

Code:

...
checking whether to build documentation... yes
checking for doxygen... yes
checking for E_REMOTE... no
configure: error: Package requirements (
  ecore >= 1.0.999
  ecore-ipc >= 1.0.999
  eet >= 1.4.0
  eina >= 1.0.999
) were not met:

Requested 'ecore >= 1.0.999' but version of ecore is 1.0.0
Requested 'ecore-ipc >= 1.0.999' but version of ecore-ipc is 1.0.0

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables E_REMOTE_CFLAGS
and E_REMOTE_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
enlightenment failed to build.

Has anyone seen this, too, and provide a hint, how to get around it?

Thanks in advance!

gargamel

abrouwers 06-26-2011 12:45 PM

Looks like you're trying to stick to 1.0.x releases of EFL, but update to e17 from trunk. That won't work - e17 needs newer versions of all EFL components too, just as the configure script mentions.

So, if you're after e17 from trunk, you'll have to do all components from trunk; running the e17.SlackBuild without any parameters will run through all components.

Good luck!

diamondsandrain 06-26-2011 02:40 PM

Not about the problem as I've been using the slacke17 build, but I wanted to state my liking of e17 as well. I started using it when Arch made the jump to Gnome3. I cancelled the upgrade and thought about it for a bit before finally deciding to do it. I hated it, so I started searching and found e17. Funny thing is that I think I like e17 more than I liked gnome2. I guess even though I didn't like Gnome3 I have to thank it for opening my eyes to something new and different.

Personally, I love that my dual monitor setup has independent virtual screens. Switching on one display doesn't affect what is on the other. I haven't seen that anywhere else. Perhaps slacke17 isn't as up to date as the svn, but I find the e17 build I use in Slackware to function better than the svn in Arch.

Daniel

gargamel 06-26-2011 04:03 PM

Quote:

Originally Posted by abrouwers (Post 4396265)
Looks like you're trying to stick to 1.0.x releases of EFL, but update to e17 from trunk. That won't work - e17 needs newer versions of all EFL components too, just as the configure script mentions.

So, if you're after e17 from trunk, you'll have to do all components from trunk; running the e17.SlackBuild without any parameters will run through all components.

Good luck!

Thanks for the quick response!
But this is not it. Actually I have:

Code:

$ ls /var/adm/packages/*p60702*
/var/adm/packages/e_dbus-1.0.0_p60702-x86_64-1_ajb  /var/adm/packages/eina-1.0.0_p60702-x86_64-1_ajb
/var/adm/packages/ecore-1.0.0_p60702-x86_64-1_ajb  /var/adm/packages/embryo-1.0.0_p60702-x86_64-1_ajb
/var/adm/packages/edje-1.0.0_p60702-x86_64-1_ajb    /var/adm/packages/engage-1.0.0_p60702-x86_64-1_ajb
/var/adm/packages/eet-1.4.0_p60702-x86_64-1_ajb    /var/adm/packages/evas-1.0.0_p60702-x86_64-1_ajb
/var/adm/packages/efreet-1.0.0_p60702-x86_64-1_ajb

As far as I an tell, these are the latest versions from trunk. I checked them out today using your script. Unfortunately, this action deleted all other files, including the directories with the SlackBuild scripts and the slackdesc files. I downloaded them again, put the *.tar.bz2 files into the directory src and ran e17.SlackBuild again. Everything seemed to go fine for a while, but then I got an error message for ecore, complaining about a wrong version number.
I fixed this by explicitly specifying the version number of the *.tar.bz2 file in ecore.SlackBuild and was able to install all the EFL files. Only problem left: I can't build the latest version of Enlightenment DR17 itself.

EDIT: I just tried it again with the latest version from trunk, no p60706, after deinstalling e17 and all EFL packages, in order to have a clean environment. Same result.

EDIT: Tried to go back to SBo. Unable to build e17, though. Guess, the problem is "multilib" (I'm on Slackware64-13.37), but currently I need this setup, so I can't verify it.

Any help appreciated!

Thanks,

gargamel

gargamel 07-16-2011 05:00 AM

Hi,

like the US football ("soccer") girls, I am not giving up. ;)

I have "purified" my system, it is now 64-bit only, again. So I just gave it another try. Unfortunately, the build process failed again, when e17 with an error message regarding unsatisfied dependencies. e17 expects version >= 1.0.999 of ecore and other components, but this does not correspond to the build numbers used for the .tar.bz2 files created, and therefore the files or packages cannot be found by the script make or configure or configure.ac script (or whichever it was).

Some further remarks. The README file doesn't mention a few details. Most important: The directory structure must be the same as the one on the download page, i. e.:

  • e17.SlackBuild expects to find the .tar.bz2 files in a directory named ./src by default. This directory has to be created manually.
  • The checkout script downloads to the current directory, so it is the simplest thing to do, to put it into ./src.
  • The SlackBuild scripts and the slackdesc files for the individual components must be in individual directories, such as ./ecore, ./e_dbus and ./enlightenment.

Maybe this is clear for most people. For me, however, it wasn't obvious, because the README file doesn't mention that all the directories must exist with the correct content. It might help less experienced users to include this information in the README file.

However, this is easy to find out. The dependency problem, however, is much more difficult to track down, I am afraid.

Cheers

gargamel

abrouwers 07-16-2011 07:45 AM

Quote:

Originally Posted by gargamel (Post 4416379)
Hi,

I have "purified" my system, it is now 64-bit only, again. So I just gave it another try. Unfortunately, the build process failed again, when e17 with an error message regarding unsatisfied dependencies. e17 expects version >= 1.0.999 of ecore and other components, but this does not correspond to the build numbers used for the .tar.bz2 files created, and therefore the files or packages cannot be found by the script make or configure or configure.ac script (or whichever it was).

Simply put, you need to run the entire e17 from SVN. This is the default of what the slackbuild does - builds all components from trunk. If you have installed ecore 1.0.1 from SlackBuilds.org, it is not new enough. Just run the e17.SlackBuild without any arguments at all, and it will run through the entire stack.

Quote:

Some further remarks. The README file doesn't mention a few details. Most important: The directory structure must be the same as the one on the download page, i. e.:

[*]e17.SlackBuild expects to find the .tar.bz2 files in a directory named ./src by default. This directory has to be created manually.

The script I wrote, e17_checkout.sh, alrady makes .tar.bz2 files by default :-)

Quote:

[*]The checkout script downloads to the current directory, so it is the simplest thing to do, to put it into ./src.

sure, the slackbuilds *expect* to find the source tarballs in src/ . Just go in to that directory, and run the e17_checkout.sh - don't change anything.

Quote:

[*]The SlackBuild scripts and the slackdesc files for the individual components must be in individual directories, such as ./ecore, ./e_dbus and ./enlightenment.

See below to grab the entire structure at once.

Quote:


Again, this is what the way the slackbuilds are structured - don't try to change the layout. Just download the entire structure as-is, run the e17_checkout.sh, and then execute the slackbuild script.

Sorry for your troube. I think the problem is that you are only downloading portions of the e17 stuff, and trying to build only e17 out of the stack, while having the other deps installed from slackbuilds.org.

If you're having trouble downloading the entire structure, try using lftp:

$ lftp -c "open http://slackadelic.com/~thrice/; mirror e17"

And again, for the dep problem, just run *all* of the stuff from SVN (ie, the defaults on the slackbuild when run with no arguments).

gargamel 07-16-2011 09:45 AM

Thanks for your kind reply!

However, what you suggest is exactly what I did. I ran e17_checkout.sh from within ./src and then e17.SlackBuild without any options or modifications. I did NOT try to build invidual components. Now, I tried it again. This is what I did:

As root I deinstalled all e packages and removed all packages and source files from /tmp. Then, as a normal user:

Code:

$ lftp -c "open http://slackadelic.com/~thrice/; mirror e17"
$ chmod a+x */*.SlackBuild
$ chmod a+x e17.*

Then as root:
Code:

# ./e17.SlackBuild
And here is what I got:

Code:

checking which device backend to use... ehal
configure: HAL mounting disabled
configure: udisks mounting disabled
checking for eeze_disk_function in -leeze... no
checking whether to build documentation... yes
checking for doxygen... yes
checking for E_REMOTE... no
configure: error: Package requirements (
  ecore >= 1.0.999
  ecore-ipc >= 1.0.999
  eet >= 1.4.0
  eina >= 1.0.999
) were not met:

No package 'ecore' found
No package 'ecore-ipc' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables E_REMOTE_CFLAGS
and E_REMOTE_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
enlightenment failed to build.

Some components have been installed, though, including ecore:

Code:

# ls /var/adm/packages/e*
/var/adm/packages/e2fsprogs-1.41.14-x86_64-1        /var/adm/packages/emacs-23.3-x86_64-1
/var/adm/packages/e_dbus-1.0.0_p61423-x86_64-1_ajb  /var/adm/packages/embryo-1.0.0_p61423-x86_64-1_ajb
/var/adm/packages/ebook-tools-0.1.1-x86_64-2        /var/adm/packages/enchant-1.5.0-x86_64-1
/var/adm/packages/ecore-1.0.0_p61423-x86_64-1_ajb  /var/adm/packages/encodings-1.0.4-noarch-1
/var/adm/packages/ed-1.4-x86_64-1                  /var/adm/packages/enscript-1.6.5.2-x86_64-1
/var/adm/packages/editres-1.0.5-x86_64-1            /var/adm/packages/epic5-1.1.2-x86_64-1
/var/adm/packages/edje-1.0.0_p61423-x86_64-1_ajb    /var/adm/packages/esound-0.2.41-x86_64-1
/var/adm/packages/eet-1.4.0_p61423-x86_64-1_ajb    /var/adm/packages/etc-13.013-x86_64-1
/var/adm/packages/efreet-1.0.0_p61423-x86_64-1_ajb  /var/adm/packages/ethtool-2.6.36-x86_64-1
/var/adm/packages/eina-1.0.0_p61423-x86_64-1_ajb    /var/adm/packages/evas-1.0.0_p61423-x86_64-1_ajb
/var/adm/packages/eject-2.1.5-x86_64-2              /var/adm/packages/evieext-1.1.1-noarch-1
/var/adm/packages/electricsheep-20090306-x86_64-3  /var/adm/packages/exiv2-0.21.1-x86_64-1
/var/adm/packages/elm-2.5.8-x86_64-3                /var/adm/packages/expat-2.0.1-x86_64-2
/var/adm/packages/elvis-2.2_0-x86_64-2              /var/adm/packages/expect-5.44.1.15-x86_64-1

So all EFL parts have the right version, taken from the .tar.bz2 files in ./src:

Code:

$ ls src
e17_checkout.sh              eet-1.4.0_p61423.tar.bz2    engage-1.0.0_p61423.tar.bz2
e_dbus-1.0.0_p61423.tar.bz2  efreet-1.0.0_p61423.tar.bz2  enlightenment-0.16.999_p61423.tar.bz2
ecore-1.0.0_p61423.tar.bz2  eina-1.0.0_p61423.tar.bz2    evas-1.0.0_p61423.tar.bz2
edje-1.0.0_p61423.tar.bz2    embryo-1.0.0_p61423.tar.bz2

Now, it seems quite obvious, that ecore 1.0.999 cannot be found, it even doesn't make sense that it is being searched for. The question is: Where is this dependency defined, and why? And how come, that you obviously cannot reproduce this problem?

As far as I can tell I did precisely follow your advice. However, the problem persists. I'd appreciate any hint what to look for or how to track this down.

EDIT: According to your profile you're on -current. Is it Slackware-current or Slackware64-current? Maybe something is different in our build environments... Just guessing though, no idea, what the actual cause is.

Any help appreciated! Thanks again!

gargamel

abrouwers 07-16-2011 11:13 AM

Ah, great. Glad to know you weren't mixing and matching :-) People commonly try to stick to 1.0.x EFL components, but use the latest enlightenment code.

I don't think running -current has anything to do with it. Actually, I just tested on a fresh 13.37 chroot environment, and the build went perfectly well, following the exact steps you pasted above (after installing lua, too). Brand new, un-touched 13.37 chroot installed to ~/build:

"Installing package enlightenment-0.16.999_p61426-x86_64-1_ajb.tgz..."

For some reason, you have ecore, eina, eet, etc. from SVN, which should satisfy the configure script. Is it possible that you have lingering, older versions around some place ? Perhaps compiled by hand to /usr/local/, or in /opt ?

bash-4.1# pkg-config --modversion ecore
1.0.999.0
bash-4.1# pkg-config --modversion eina
1.0.999.0
bash-4.1# pkg-config --modversion eet
1.4.999.0

gargamel 07-16-2011 02:35 PM

Hmm, no traces of previous installations of any EFL parts, neither in /opt nor in /usr/local.
But:
Code:

# pkg-config --modversion ecore
Package ecore was not found in the pkg-config search path.
Perhaps you should add the directory containing `ecore.pc'
to the PKG_CONFIG_PATH environment variable
No package 'ecore' found
# pkg-config --modversion eina
1.0.999.0
# pkg-config --modversion eet
1.4.999.0

And again:

Code:

# ls /var/adm/packages/*ajb
/var/adm/packages/e_dbus-1.0.0_p61423-x86_64-1_ajb  /var/adm/packages/efreet-1.0.0_p61423-x86_64-1_ajb
/var/adm/packages/ecore-1.0.0_p61422-x86_64-1_ajb  /var/adm/packages/eina-1.0.0_p61423-x86_64-1_ajb
/var/adm/packages/edje-1.0.0_p61423-x86_64-1_ajb    /var/adm/packages/embryo-1.0.0_p61423-x86_64-1_ajb
/var/adm/packages/eet-1.4.0_p61423-x86_64-1_ajb    /var/adm/packages/evas-1.0.0_p61423-x86_64-1_ajb

Weird! For eina and eet pkg-config returns the expected value, but ecore seems not to be there, although it is definitely installed as a package.

My system is not a fresh install. I have installed some multimedia stuff from SBo, and it was a multiuser system before. I reverted it to pure 64 bit, because I couldn't build e17 from SBo on the multilib install. After removing all multilib stuff using
Code:

# slackpkg clean-system
e17 from SBo works again. Now, as I said, I deinstalled that completely, before trying to build from SVN trunk using your scripts. The results are confusing, I'd say, and I am plain frankly clueless.

Maybe, I have to re-install my system, but as I need it for daily work this would not be going to happen for a while. Thanks a lot for your kind support, anyway! I'll try again, in due course! :)

gargamel

abrouwers 07-16-2011 03:07 PM

What are the contents of the ecore package? Did it actually get created properly, and have useful things that E will search for? It sounds like perhaps the ecore package is bogus.

Specifically, items like:

usr/lib64/pkgconfig/
usr/lib64/pkgconfig/ecore-x.pc
usr/lib64/pkgconfig/ecore-fb.pc
usr/lib64/pkgconfig/ecore-imf.pc
usr/lib64/pkgconfig/ecore-imf-evas.pc
usr/lib64/pkgconfig/ecore-con.pc
usr/lib64/pkgconfig/ecore-file.pc
usr/lib64/pkgconfig/ecore-evas.pc
usr/lib64/pkgconfig/ecore-input-evas.pc
usr/lib64/pkgconfig/ecore-input.pc
usr/lib64/pkgconfig/ecore.pc
usr/lib64/pkgconfig/ecore-ipc.pc

And on my machine, as an example:

bash-4.1# cat /usr/lib64/pkgconfig/ecore.pc
prefix=/usr
exec_prefix=${prefix}
libdir=/usr/lib64
includedir=${prefix}/include

Name: ecore
Description: Ecore event abstraction library
Requires.private: glib-2.0 eina >= 1.0.0
Version: 1.0.999.0
Libs: -L${libdir} -lecore
Libs.private: -lm
Cflags: -I${includedir}/ecore-1


All times are GMT -5. The time now is 05:50 AM.