lugoteehalt
08-06-2007, 02:27 PM
Installing Enlightenment E17 from source on Debian Etch
E17 (more correctly DR17 for Development Release 17) is the upcoming version of the window manager Enlightenment. Designated 'unstable' but AFIK quite well behaved; and deemed by its advocates the next step in desk tops, superseding Windows-like environments. It is gratifying that they are not interested in the things we are all supposed to be interested in; they care, they say, only for ART. The keynotes are configurability and over-the-top, but tasteful, eye candy.
I am not an expert, normally avoiding installing from source, but the following seems to have worked reasonably well. An unofficial .deb package may be available http://shadoi.soulmachine.net.
UPDATE
Installed the 'latest' (18-May-2008 17:29) version of E17 from download.enlightenment.org/snapshots (http://download.enlightenment.org/snapshots) yesterday, on a flash drive. It runs reasonably from the flash drive. So here is how I did this, it is still Etch but on AMD64 architecture.
Download all the stuff from above link, 'latest'. Then:
$ tar jvxf filename.tar.bz2
to unpack the archive.
Then cd into the directory that has just been created and do something like:
./configure --prefix=/home/lugo/flash3/dr17/Enlightenment PKG_CONFIG_PATH=/media/flash3/dr17/ecore-0.9.9.043:/home/lugo/flash3/dr17/Enlightenment/lib/pkgconfig
The PKG_ stuff will not be necessary for the first few items.
The --prefex=/something/or/other is the directory in which all the E17 stuff will end up; in my case the Enlightenment directory on the flash drive.
Then do
make
make install
make clean - do not know if this is desirable.
In the ecore-0.9.9.043 directory doing ./configure --help|less reveals the configure option: --enable-ecore-evas-x11-gl. Oddly this option seems to have been disabled by default - it is odd because ecore-evas is needed. So, in the ecore-0.9.9.043 directory do something like:
$ ./configure --prefix=/home/lugo/flash3/dr17/Enlightenment --enable-ecore-evas-x11-gl PKG_CONFIG_PATH=/home/lugo/flash3/dr17/Enlightenment/lib/pkgconfig
It may be necessary to add some of the other options too, I cannot recall.
If it cannot find some package that it need try locating the thingThatItNeeds.pc file with locate:
As root
# updatedb
then
$ locate thingThatItNeeds.pc
and add the *path* to this file, i.e. omit thingThatItNeeds.pc, to PKG_CONFIG_PATH. E.g. PKG_CONFIG_PATH=/home/lugo/flash3/dr17/Enlightenment/lib/pkgconfig:/said/path.
In order to get enlightenment-0.16.999.043 in it seems necessary to add the /bin directory to your PATH. In the .bashrc or .bash_profile or where ever file append :/home/lugo/flash3/dr17/Enlightenment/bin. Then reboot, I hard rebooted - shoved a biro in the hole at the front.
To use DR17 put
! enlightenment_start
at the end of the .xinitrc or .xsession file or whatever you use to start X. I have no idea whether the ! does any good. E17 seems to work quite well, but is buggy as would be expected. It introduced distortion into tvtime's sound with me, there may well be an easy fix. Themes and backgrounds and so on may be got from get-e.org, or the site that replaces it.
At first sight the box (AMD64 twin core; 4G of RAM) seems dramatically faster than with E16 which I normally use. This would be consistent with the lean fast programs with low memory and CPU needs which are useable on very low specification machines - Rasterman's (is it??) philosophy. It strikes me that this is not just nice guy stuff to help developing countries, but highly 'comercial', since getting greater realism in games should not just be attacked through better hardware but this sort of software too.
According to Installing Enlightenment DR17 The Slackware Handbook, forgotten the url, these thing should be installed in the given order, to give a sort of minimal set up. (I also had to add 6. efreet-0.0.3.005.tar.gz).
1. eet-0.9.10.023.tar.gz
2. evas-0.9.9.023.tar.gz
3. ecore-0.9.9.023.tar.gz
4. embryo-0.9.1.023.tar.gz
5. edje-0.5.0.023.tar.gz
6. enlightenment-0.16.999.023.tar.gz
Get these from download.enlightenment.org/snapshots/2007-05-06
Because it makes things a lot easier I'll assume the file manager mc is being used.
Become root, in general this is unnecessary, start mc outside X, and create a directory such as /root/Tarball/. Put the tarballs into Tarball. Unpack eet with
# tar -zxvf /root/Tarball/eet-0.9.10.023.tar.gz
(ctrl-shift-return puts in the /root/Tarball/eet-0.9.10.023.tar.gz, alt-return just does eet-0.9.10.023.tar.gz - very convenient for this longish job).
Navigate into the directory, there in Tarball, that tar has created: eet-0.9.10.023.
Decide whether to compile in the normal way or to turn the source into a .deb package. The later has the advantage that apt will then know what is going and will reflect this in its databases, otherwise apt will have to be told manually, which I don't know how to do. Perhaps there is a program which takes care of this? I opted to produce Debian package files, but failed with two of the sources.
To prepare the source for being turned into a package the program dh_make was used.
# dh_make -s
However this seemed already to have been done, except for one tarball where things were apparently cocked up. I did it anyway, and if it asked for
# dh_make -s -createorig
did as it wished. The -s argument means expect to produce one .deb package. Some of the tarballs produced several packages; this did not seem a problem, but who knows?
Now build the packages. Staying in the same directory do
# dpkg-buildpackage -us -uc -rsudo
For this the 'sudo' program will need to be installed - there is no need to configure sudo as long as you work as root.
The program will ask for dependencies to be installed (are 'build dependencies' the same as dependencies or can they be removed when the build is complete?) Most of these are available as Etch packages in the normal way. If a dependency cannot be found then I got away with
# dpkg-buildpackage -us -uc -rsudo -d
where -d means forget about missing dependencies.
One nasty problem is dpkg saying the file debian/rules does not exist. This means that the file 'rules' in the 'debian' directory is not executable - change its permissions.
# chmod a+x debian/rules (or do it with mc)
If dpkg works some files, including .deb file(s), will now exist in the Tarball directory, the parent directory to the one you should be in. Navigate to eet-0.9.10.023.deb or whatever and press <enter> in mc. The file opens and contains, amoung other things, an INFO and an executable install file. Read the INFO file (press F3) and install any dependencies it mentions as necessary. Then navigate to the install file and hit <enter>. This always installs the program: if dependencies are missing it will be installed anyway but left unconfigured. It often happened that dependencies were in packages yet to be installed so do
# dpkg --audit
when it seems appropriate and then
# dpkg --configure <package0> <package1> ....
using the list of packages supplied by dpkg --audit.
The above procedures worked for all the tarballs except two, one of which was the enlightenment tarball. With these I resorted to simply installing in the normal way. In the same directory in which dpkg-buildpackage was used, do
# ./configure
then
# make
then
# make install
then
# make clean (Do not know if there is any point to this.)
This completes the installation of E17.
It seems reasonable to uninstall the earlier Enlightenment. Perhaps the easiest way to start the new Enlightenment is have a [how come an sounds right?] .xsession or .xinitrc file (one of these is, from memory, deprecated) with
! enlightenment_start
as the last line. There must be no & at the end of this line. If you are unfamiliar with these files it is safest to have this as the only line, otherwise there is a risk of X starting and then quickly stopping. The Enlightenment boys and girls might prefer this anyway.
Enlightenment starts with a blitz of eyecandy and then, in my case, tries to repair itself. It only started working sensibly after segfaulting. Is this usual for programs - that they try to fix themselves? This would account for Linux often seeming to put itself right.
Now all we need is a How I Did It about configuring the program, especially transparent Eterms and Escreens. (Incidentally $ enlightenment -help yields, among other things, -good .... be good, -bad .... be bad, and -paranoid .... be paranoid.)
E17 (more correctly DR17 for Development Release 17) is the upcoming version of the window manager Enlightenment. Designated 'unstable' but AFIK quite well behaved; and deemed by its advocates the next step in desk tops, superseding Windows-like environments. It is gratifying that they are not interested in the things we are all supposed to be interested in; they care, they say, only for ART. The keynotes are configurability and over-the-top, but tasteful, eye candy.
I am not an expert, normally avoiding installing from source, but the following seems to have worked reasonably well. An unofficial .deb package may be available http://shadoi.soulmachine.net.
UPDATE
Installed the 'latest' (18-May-2008 17:29) version of E17 from download.enlightenment.org/snapshots (http://download.enlightenment.org/snapshots) yesterday, on a flash drive. It runs reasonably from the flash drive. So here is how I did this, it is still Etch but on AMD64 architecture.
Download all the stuff from above link, 'latest'. Then:
$ tar jvxf filename.tar.bz2
to unpack the archive.
Then cd into the directory that has just been created and do something like:
./configure --prefix=/home/lugo/flash3/dr17/Enlightenment PKG_CONFIG_PATH=/media/flash3/dr17/ecore-0.9.9.043:/home/lugo/flash3/dr17/Enlightenment/lib/pkgconfig
The PKG_ stuff will not be necessary for the first few items.
The --prefex=/something/or/other is the directory in which all the E17 stuff will end up; in my case the Enlightenment directory on the flash drive.
Then do
make
make install
make clean - do not know if this is desirable.
In the ecore-0.9.9.043 directory doing ./configure --help|less reveals the configure option: --enable-ecore-evas-x11-gl. Oddly this option seems to have been disabled by default - it is odd because ecore-evas is needed. So, in the ecore-0.9.9.043 directory do something like:
$ ./configure --prefix=/home/lugo/flash3/dr17/Enlightenment --enable-ecore-evas-x11-gl PKG_CONFIG_PATH=/home/lugo/flash3/dr17/Enlightenment/lib/pkgconfig
It may be necessary to add some of the other options too, I cannot recall.
If it cannot find some package that it need try locating the thingThatItNeeds.pc file with locate:
As root
# updatedb
then
$ locate thingThatItNeeds.pc
and add the *path* to this file, i.e. omit thingThatItNeeds.pc, to PKG_CONFIG_PATH. E.g. PKG_CONFIG_PATH=/home/lugo/flash3/dr17/Enlightenment/lib/pkgconfig:/said/path.
In order to get enlightenment-0.16.999.043 in it seems necessary to add the /bin directory to your PATH. In the .bashrc or .bash_profile or where ever file append :/home/lugo/flash3/dr17/Enlightenment/bin. Then reboot, I hard rebooted - shoved a biro in the hole at the front.
To use DR17 put
! enlightenment_start
at the end of the .xinitrc or .xsession file or whatever you use to start X. I have no idea whether the ! does any good. E17 seems to work quite well, but is buggy as would be expected. It introduced distortion into tvtime's sound with me, there may well be an easy fix. Themes and backgrounds and so on may be got from get-e.org, or the site that replaces it.
At first sight the box (AMD64 twin core; 4G of RAM) seems dramatically faster than with E16 which I normally use. This would be consistent with the lean fast programs with low memory and CPU needs which are useable on very low specification machines - Rasterman's (is it??) philosophy. It strikes me that this is not just nice guy stuff to help developing countries, but highly 'comercial', since getting greater realism in games should not just be attacked through better hardware but this sort of software too.
According to Installing Enlightenment DR17 The Slackware Handbook, forgotten the url, these thing should be installed in the given order, to give a sort of minimal set up. (I also had to add 6. efreet-0.0.3.005.tar.gz).
1. eet-0.9.10.023.tar.gz
2. evas-0.9.9.023.tar.gz
3. ecore-0.9.9.023.tar.gz
4. embryo-0.9.1.023.tar.gz
5. edje-0.5.0.023.tar.gz
6. enlightenment-0.16.999.023.tar.gz
Get these from download.enlightenment.org/snapshots/2007-05-06
Because it makes things a lot easier I'll assume the file manager mc is being used.
Become root, in general this is unnecessary, start mc outside X, and create a directory such as /root/Tarball/. Put the tarballs into Tarball. Unpack eet with
# tar -zxvf /root/Tarball/eet-0.9.10.023.tar.gz
(ctrl-shift-return puts in the /root/Tarball/eet-0.9.10.023.tar.gz, alt-return just does eet-0.9.10.023.tar.gz - very convenient for this longish job).
Navigate into the directory, there in Tarball, that tar has created: eet-0.9.10.023.
Decide whether to compile in the normal way or to turn the source into a .deb package. The later has the advantage that apt will then know what is going and will reflect this in its databases, otherwise apt will have to be told manually, which I don't know how to do. Perhaps there is a program which takes care of this? I opted to produce Debian package files, but failed with two of the sources.
To prepare the source for being turned into a package the program dh_make was used.
# dh_make -s
However this seemed already to have been done, except for one tarball where things were apparently cocked up. I did it anyway, and if it asked for
# dh_make -s -createorig
did as it wished. The -s argument means expect to produce one .deb package. Some of the tarballs produced several packages; this did not seem a problem, but who knows?
Now build the packages. Staying in the same directory do
# dpkg-buildpackage -us -uc -rsudo
For this the 'sudo' program will need to be installed - there is no need to configure sudo as long as you work as root.
The program will ask for dependencies to be installed (are 'build dependencies' the same as dependencies or can they be removed when the build is complete?) Most of these are available as Etch packages in the normal way. If a dependency cannot be found then I got away with
# dpkg-buildpackage -us -uc -rsudo -d
where -d means forget about missing dependencies.
One nasty problem is dpkg saying the file debian/rules does not exist. This means that the file 'rules' in the 'debian' directory is not executable - change its permissions.
# chmod a+x debian/rules (or do it with mc)
If dpkg works some files, including .deb file(s), will now exist in the Tarball directory, the parent directory to the one you should be in. Navigate to eet-0.9.10.023.deb or whatever and press <enter> in mc. The file opens and contains, amoung other things, an INFO and an executable install file. Read the INFO file (press F3) and install any dependencies it mentions as necessary. Then navigate to the install file and hit <enter>. This always installs the program: if dependencies are missing it will be installed anyway but left unconfigured. It often happened that dependencies were in packages yet to be installed so do
# dpkg --audit
when it seems appropriate and then
# dpkg --configure <package0> <package1> ....
using the list of packages supplied by dpkg --audit.
The above procedures worked for all the tarballs except two, one of which was the enlightenment tarball. With these I resorted to simply installing in the normal way. In the same directory in which dpkg-buildpackage was used, do
# ./configure
then
# make
then
# make install
then
# make clean (Do not know if there is any point to this.)
This completes the installation of E17.
It seems reasonable to uninstall the earlier Enlightenment. Perhaps the easiest way to start the new Enlightenment is have a [how come an sounds right?] .xsession or .xinitrc file (one of these is, from memory, deprecated) with
! enlightenment_start
as the last line. There must be no & at the end of this line. If you are unfamiliar with these files it is safest to have this as the only line, otherwise there is a risk of X starting and then quickly stopping. The Enlightenment boys and girls might prefer this anyway.
Enlightenment starts with a blitz of eyecandy and then, in my case, tries to repair itself. It only started working sensibly after segfaulting. Is this usual for programs - that they try to fix themselves? This would account for Linux often seeming to put itself right.
Now all we need is a How I Did It about configuring the program, especially transparent Eterms and Escreens. (Incidentally $ enlightenment -help yields, among other things, -good .... be good, -bad .... be bad, and -paranoid .... be paranoid.)