Re: [E-devel] Community Building - release
I wrote: > ... >>> As to the above mentioned steps.. I disagree with some of the >>> arguments, >>> but they are also not unreasonable - so long as everyone realizes that the >>> state >>> of many things in E is still rather basic and are willing to 'break' apis on >>> major releases when they bring good improvements.. E is still small enough >>> that >>> it can be fluid if it wants to. >>> >>> But, one very important thing to consider here is: What exactly is it >>> that >>> E wants to achieve? What are the basic 'large' goals? >>> >>> >>> >> Thats a funny one, because a lot of people say "Oh, E17 isnt as good >> as Gnome... or KDE" when its not completely a desktop environmant like >> those 2. It has a lot of the mechanics of a full DE and being so >> modular, could fill the things needed to become a full DE from that >> point. (And then you ask, whats the difference between what E17 is now >> and a full DE?!? I dont know. Ask wikipedia or something.) If it was >> competeing souly against WMs like fluxbox and friends, then thats >> already done and kicking ass. >> >> If anything, it might be an idea to ask people, what 'needs' to be >> done? I see a few people on IRC and on forums saying, "E17 is good, >> but its just not finished/has bits missing". Some lusers go as far to >> say "Err E17 is buggy and not stable! Waa" simply becuase there isnt a >> 1.0 release. >> >> Toma >> >> >> > > I'm not sure I follow some of this. There are many different things that > "E" could do or become, it's not just a question of what the wm/desktop-shell > could do/be, or even what a desktop environment of some sort could do/be. > There are questions of development 'platforms', what they might be geared > to develop, what they might emphasize, and such... and there are questions of > what kinds of apps or further libs or frameworks people might want to build > beyond that, to create some sort of coherent 'environment(s)' and such. > If you're going to "ask people", then it depends who these people are > and what kind of audience they are: end-users of apps? end-users of desktop > environments/shells/whatnot? theme designers (of what)? developers of apps? > "rich" app developers? etc. > > > Forgot to mention a few other relevant ones: developers of web apis/services? developers of gfx/canvas libs? developers of gui toolkits? ... My questions were directed at the audience consisting of all "E" developers. :) >>> If all that's really wanted is a wm/shell kind of thing, then you've >>> got it. >>> It's pretty good - could be better, etc. - but it's there. >>> >>> If some want 'development platforms' then what kinds? And which >>> apis/models >>> are best suited to build whatever with? Which can be attractive to certain >>> areas >>> more than others, etc. >>> >>> If some want to also build environments/whatnot on top of those >>> platforms, >>> then what apps/libs do you need for short, mid, long term growth? >>> >>> What are relevant models out there in open, partly-open, not-so-open >>> worlds, >>> that could be used for comparison? >>> >>> >>> Click for FHA loan, $0 lender fees, low rates & approvals nationwide http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3mItjHT46zg0b4UPUAGi6dZfbcr8x5PmjR6BgYgXGZVlZkta/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Community Building - release
Toma wrote: > On 30/07/2008, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > >> Vincent wrote: >> >> >>> Quoting Nathan Ingersoll <[EMAIL PROTECTED]>: >>> >>> One idea I discussed with Vincent today is that our lack of releases has caused many users to lose interest and stop taking notice of the project. I realize that there is a lot of talk surrounding changes to core infrastructure (data lib, graphics, scripting language, etc), but has there been any thought recently put into how our release process should be structured? There used to be a TODO list for e17, and that has been moved to Trac, but has anyone took a hard look at what is necessary for cutting a stable release? Even if we don't release e17 1.0, we may be able to move the core libs towards releases like eet. >>> Some ideas I and others have: >>> >>> 1) We must release the core libs (evas, ecore, embryo, edje, efreet and >>> e_dbus, >>> that is what is needed by e17). So we must discuss to what must be done for >>> each of them before a release. Here what I think. You can add other things I >>> have forgotten. >>> >>> * embryo: is in a very good shape. raster wanted to release it later >>> because he >>> wants to look at lua for scripting. I think that it is a very bad idea, and >>> should be delayed for the next version. What may lack is documentation. >>> >>> * evas: also in a very good shape, but several things wanted to be done: api >>> changes in polygons, gradient and data types (see below). Documentation >>> must be >>> improved too. Although polygons can be done in a rather short amount of >>> time, >>> gradient stuff can take a long time and maybe can be done (with other things >>> like vgfx) in the next evas major release. Note that Nathan and me agreed on >>> the fact that, today, we should have an evas 3.*, and not 0.9... >>> >>> * ecore: Cedric wants to reorganize some stuff in ecore_evas. Also data >>> types. >>> See next point >>> >>> * evas and ecore: data types. The problem is that it will break abi if we >>> change the data types. See below for a "solution" >>> >>> * edje: except the problem of data types, I don't see any major flaw. >>> >>> * efreet and e_dbus: I don't know much about them. They are used with e17 >>> without problem. Cedric told me that he wanted to speed up efreet. >>> There is the >>> problem of data types, though. >>> >>> The problem with data types is that it will break ABI and API. So we >>> must decide >>> if we release with or without the change in data types. >>> >>> A solution is to "release" with number version 0.10 (current version number >>> is >>> 0.9.9) without data type changes and warns that there will be big changes >>> for >>> 1.0. >>> >>> 2) A release manager must be named. What he should do: >>> >>> * decide which library may be released because of a certain amount of >>> important >>> bugs have been fixed. Of course, this should be discussed in the ML for >>> example. >>> >>> * sent mails to warn about pre-releases (in that period, only bug fixes >>> and doc >>> changes are allowed. Maybe other things i can't think of.) and releases >>> >>> * of course, provide the tar balls for pre-releases and releases >>> >>> * maybe add news on some sites like osnews, /., freshmeat or phoronix >>> >>> >>> Even if there are 0.10 releases before a 1.0, the fact that we announce such >>> release is a good thing. As an example, Kim is doing e16 releases >>> periodically. >>> Each time one is done, a user announce that on osnews. And i often read >>> in those >>> news that people are happy to see that e16 is still maintained. >>> >>> Comments, ideas ? >>> >>> Vincent >>> >>> >> It's good to see such attempts and I hope they continue. I'd also like >> to >> applaud Carsten for taking the high-road, and I hope that E can become a more >> inclusive project able to honestly embrace differences, attract developers, >> and >> work with others. >> >> As to the above mentioned steps.. I disagree with some of the arguments, >> but they are also not unreasonable - so long as everyone realizes that the >> state >> of many things in E is still rather basic and are willing to 'break' apis on >> major releases when they bring good improvements.. E is still small enough >> that >> it can be fluid if it wants to. >> >> But, one very important thing to consider here is: What exactly is it >> that >> E wants to achieve? What are the basic 'large' goals? >> >> > > Thats a funny one, because a lot of people say "Oh, E17 isnt as good > as Gnome... or KDE" when its not completely a desktop environmant like > those 2. It has a lot of the mechanics of a full DE and being so > modular, could fill the things needed to become a full DE from that > point. (And then you ask, whats the difference between what E17 is now > and a full DE?!? I dont know. Ask wikipedia or something.) If it was > competeing souly against WMs like
Re: [E-devel] Community Building - release
On 30/07/2008, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > Vincent wrote: > > > Quoting Nathan Ingersoll <[EMAIL PROTECTED]>: > > > >> One idea I discussed with Vincent today is that our lack of releases > >> has caused many users to lose interest and stop taking notice of the > >> project. I realize that there is a lot of talk surrounding changes to > >> core infrastructure (data lib, graphics, scripting language, etc), but > >> has there been any thought recently put into how our release process > >> should be structured? There used to be a TODO list for e17, and that > >> has been moved to Trac, but has anyone took a hard look at what is > >> necessary for cutting a stable release? Even if we don't release e17 > >> 1.0, we may be able to move the core libs towards releases like eet. > >> > > > > Some ideas I and others have: > > > > 1) We must release the core libs (evas, ecore, embryo, edje, efreet and > > e_dbus, > > that is what is needed by e17). So we must discuss to what must be done for > > each of them before a release. Here what I think. You can add other things I > > have forgotten. > > > > * embryo: is in a very good shape. raster wanted to release it later > > because he > > wants to look at lua for scripting. I think that it is a very bad idea, and > > should be delayed for the next version. What may lack is documentation. > > > > * evas: also in a very good shape, but several things wanted to be done: api > > changes in polygons, gradient and data types (see below). Documentation > > must be > > improved too. Although polygons can be done in a rather short amount of > > time, > > gradient stuff can take a long time and maybe can be done (with other things > > like vgfx) in the next evas major release. Note that Nathan and me agreed on > > the fact that, today, we should have an evas 3.*, and not 0.9... > > > > * ecore: Cedric wants to reorganize some stuff in ecore_evas. Also data > > types. > > See next point > > > > * evas and ecore: data types. The problem is that it will break abi if we > > change the data types. See below for a "solution" > > > > * edje: except the problem of data types, I don't see any major flaw. > > > > * efreet and e_dbus: I don't know much about them. They are used with e17 > > without problem. Cedric told me that he wanted to speed up efreet. > > There is the > > problem of data types, though. > > > > The problem with data types is that it will break ABI and API. So we > > must decide > > if we release with or without the change in data types. > > > > A solution is to "release" with number version 0.10 (current version number > > is > > 0.9.9) without data type changes and warns that there will be big changes > > for > > 1.0. > > > > 2) A release manager must be named. What he should do: > > > > * decide which library may be released because of a certain amount of > > important > > bugs have been fixed. Of course, this should be discussed in the ML for > > example. > > > > * sent mails to warn about pre-releases (in that period, only bug fixes > > and doc > > changes are allowed. Maybe other things i can't think of.) and releases > > > > * of course, provide the tar balls for pre-releases and releases > > > > * maybe add news on some sites like osnews, /., freshmeat or phoronix > > > > > > Even if there are 0.10 releases before a 1.0, the fact that we announce such > > release is a good thing. As an example, Kim is doing e16 releases > > periodically. > > Each time one is done, a user announce that on osnews. And i often read > > in those > > news that people are happy to see that e16 is still maintained. > > > > Comments, ideas ? > > > > Vincent > > > > It's good to see such attempts and I hope they continue. I'd also like to > applaud Carsten for taking the high-road, and I hope that E can become a more > inclusive project able to honestly embrace differences, attract developers, > and > work with others. > > As to the above mentioned steps.. I disagree with some of the arguments, > but they are also not unreasonable - so long as everyone realizes that the > state > of many things in E is still rather basic and are willing to 'break' apis on > major releases when they bring good improvements.. E is still small enough > that > it can be fluid if it wants to. > > But, one very important thing to consider here is: What exactly is it > that > E wants to achieve? What are the basic 'large' goals? > Thats a funny one, because a lot of people say "Oh, E17 isnt as good as Gnome... or KDE" when its not completely a desktop environmant like those 2. It has a lot of the mechanics of a full DE and being so modular, could fill the things needed to become a full DE from that point. (And then you ask, whats the difference between what E17 is now and a full DE?!? I dont know. Ask wikipedia or something.) If it was competeing souly against WMs like fluxbox and friends, then thats already done and kicking ass. If anything, it might be an idea to ask p
Re: [E-devel] E CVS: proto/eina doursse
One 'alarming' question. Does the name mean anything? Why not pick a simple and descriptive name, that most people will understand (like edata, or something a bit more shocking and provokative, without a leading 'e') On Wed, 2008-07-30 at 17:04 +0200, Nicolas Aguirre wrote: > Should we now use eina instead of evas_data and ecore_data in EFL projects ? > Why ? Have you benchmarks ? Unit Tests :P ? > > In case of ecore_file for example, functions return Ecore_List. Do you plan > to move gradually to eina ? > > I think that's a good plan to unify lists and hashs in EFL :) > > Regards, > Nico > > 2008/7/30 Enlightenment CVS <[EMAIL PROTECTED]> > > > Enlightenment CVS committal > > > > Author : doursse > > Project : e17 > > Module : proto/eina > > > > Dir : e17/proto/eina > > > > > > Modified Files: > >Makefile.am configure.in > > > > > > Log Message: > > add unit test and coverage support in configure.in and Makefile.am. Now > > let's encourage Cedric for writing the unit tests :) > > > > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina doursse
On Wed, Jul 30, 2008 at 5:04 PM, Nicolas Aguirre <[EMAIL PROTECTED]> wrote: > Should we now use eina instead of evas_data and ecore_data in EFL projects ? > Why ? Have you benchmarks ? Unit Tests :P ? You are too quick :) We need to work a little bit more before switching. But that's the plan. > In case of ecore_file for example, functions return Ecore_List. Do you plan > to move gradually to eina ? When we believe that eina is ready for prime time, we will move it too libs and then start moving all library away from Evas_Data and Ecore_Data. We are no there yet, so first code > I think that's a good plan to unify lists and hashs in EFL :) Yep that's the plan, and now that's eina is in cvs, any one can review it, and help us improve it. > 2008/7/30 Enlightenment CVS <[EMAIL PROTECTED]> > >> Enlightenment CVS committal >> >> Author : doursse >> Project : e17 >> Module : proto/eina >> >> Dir : e17/proto/eina >> >> >> Modified Files: >>Makefile.am configure.in >> >> >> Log Message: >> add unit test and coverage support in configure.in and Makefile.am. Now >> let's encourage Cedric for writing the unit tests :) >> >> > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- Cedric BAIL - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina doursse
Should we now use eina instead of evas_data and ecore_data in EFL projects ? Why ? Have you benchmarks ? Unit Tests :P ? In case of ecore_file for example, functions return Ecore_List. Do you plan to move gradually to eina ? I think that's a good plan to unify lists and hashs in EFL :) Regards, Nico 2008/7/30 Enlightenment CVS <[EMAIL PROTECTED]> > Enlightenment CVS committal > > Author : doursse > Project : e17 > Module : proto/eina > > Dir : e17/proto/eina > > > Modified Files: >Makefile.am configure.in > > > Log Message: > add unit test and coverage support in configure.in and Makefile.am. Now > let's encourage Cedric for writing the unit tests :) > > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [RFC] EET signature support
Hi guys,
So here is a little patch that signature support to eet. It append
at the end of a classic eet file a signature and the public x509
certificate in der format. This change doesn't break file
compatibility as the signature is automatically detected based on the
file content against it's size. But this means, that eet_open first
make an attempt to load the file structure (directory and dictionnary)
before checking the signature. It use openssl library and the test
provided in eet_suite.c work well with openssl version 0.9.8e.
Before I start adding crypto support every where in eet, plese
review this patch and give me your feedback. Have fun !
--
Cedric BAIL
diff --git a/configure.in b/configure.in
index ebf301e..e2eba51 100644
--- a/configure.in
+++ b/configure.in
@@ -117,6 +117,22 @@ int main (int argc, char **argv) {
], AC_MSG_WARN([Cannot check when cross-compiling -- assuming null is okay])
)
+dnl Disable support for old eet file format.
+old_eet_file_format="yes"
+AC_ARG_ENABLE(old-eet-file-format,
+ AC_HELP_STRING(
+[--disable-old-eet-file-format],
+[disable old eet file format support. [[default=enabled]]]
+ ),
+ [ old_eet_file_format=$enableval ]
+)
+AM_CONDITIONAL(EET_OLD_EET_FILE_FORMAT, test "x$old_eet_file_format" = "xyes")
+if test "x$old_eet_file_format" = "xyes"; then
+ AC_DEFINE(EET_OLD_EET_FILE_FORMAT, 1, [support old eet file format])
+else
+ AC_DEFINE(EET_OLD_EET_FILE_FORMAT, 0, [support old eet file format])
+fi
+
dnl Unit Tests
AC_ARG_ENABLE(tests,
@@ -143,6 +159,54 @@ fi
AM_CONDITIONAL(EET_ENABLE_TESTS, test "x${enable_tests}" = "xyes")
+dnl Openssl support
+want_openssl="auto"
+have_openssl="no"
+AC_ARG_ENABLE(openssl,
+ [AC_HELP_STRING([--disable-openssl], [disable openssl eet support])],
+ [ want_openssl=$enableval ]
+)
+if test "x$want_openssl" = "xyes" -o "x$want_openssl" = "xauto"; then
+ PKG_CHECK_MODULES(OPENSSL, openssl,
+[
+ have_openssl="yes"
+ AC_DEFINE(HAVE_OPENSSL, 1, [Have Openssl support])
+],
+[
+ if test "x$use_strict" = "xyes"; then
+AC_MSG_ERROR([Openssl not found (strict dependencies checking)])
+ fi
+])
+fi
+
+dnl Crypto option
+want_cypher="yes"
+have_cypher="yes"
+want_signature="yes"
+have_signature="yes"
+
+AC_MSG_CHECKING(whether to activate cypher support in eet)
+AC_ARG_ENABLE(cypher,
+ [AC_HELP_STRING([--disable-cypher], [disable cypher support for eet API])],
+ [ want_cypher=$enableval ]
+)
+if test "x$have_openssl" = "xyes" -a "x$want_cypher" = "xyes"; then
+ have_cypher="yes"
+ AC_DEFINE(HAVE_CYPHER, 1, [Have cypher support built in eet])
+fi
+AC_MSG_RESULT($have_cypher)
+
+AC_MSG_CHECKING(whether to activate signature support in eet)
+AC_ARG_ENABLE(signature,
+ [AC_HELP_STRING([--disable-signature], [disable signature file support for eet])],
+ [ want_signature=$enableval ]
+)
+if test "x$have_signature" = "xyes" -a "x$want_signature" = "xyes"; then
+ have_signature="yes"
+ AC_DEFINE(HAVE_SIGNATURE, 1, [Have signature support for eet file])
+fi
+AC_MSG_RESULT($have_signature)
+
dnl Coverage
AC_ARG_ENABLE(coverage,
@@ -241,6 +305,12 @@ echo ""
echo
echo "Configuration Options Summary:"
echo
+echo " Openssl..: ${have_openssl}"
+echo "Cypher support.: ${have_cypher}"
+echo "Signature..: ${have_signature}"
+
+echo " Old eet file format..: ${old_eet_file_format}"
+echo
echo " Tests: ${enable_tests}"
echo " Coverage.: ${enable_coverage}"
echo
diff --git a/src/lib/Eet.h b/src/lib/Eet.h
index dc7a383..35ad69b 100644
--- a/src/lib/Eet.h
+++ b/src/lib/Eet.h
@@ -86,12 +86,19 @@ extern "C" {
EET_ERROR_WRITE_ERROR_FILE_TOO_BIG,
EET_ERROR_WRITE_ERROR_IO_ERROR,
EET_ERROR_WRITE_ERROR_OUT_OF_SPACE,
- EET_ERROR_WRITE_ERROR_FILE_CLOSED
+ EET_ERROR_WRITE_ERROR_FILE_CLOSED,
+ EET_ERROR_MMAP_FAILED,
+ EET_ERROR_X509_ENCODING_FAILED,
+ EET_ERROR_SIGNATURE_FAILED,
+ EET_ERROR_INVALID_SIGNATURE,
+ EET_ERROR_NOT_SIGNED,
+ EET_ERROR_NOT_IMPLEMENTED
} Eet_Error;
typedef struct _Eet_File Eet_File;
typedef struct _Eet_DictionaryEet_Dictionary;
typedef struct _Eet_Data_Descriptor Eet_Data_Descriptor;
+ typedef struct _Eet_Key Eet_Key;
typedef struct _Eet_Data_Descriptor_Class Eet_Data_Descriptor_Class;
@@ -237,6 +244,39 @@ extern "C" {
*/
EAPI Eet_Error eet_close(Eet_File *ef);
+ /**
+* Create an Eet_Key needed for signing an eet file.
+*
+* The certificate should provide the public that match the private key.
+* No verification is done to ensure that.
+*
+* @since 2.0.0
+*/
+ EAPI Eet_Key* eet_identity_open(const char *certificate_file, const char *private_key_file);
+
+/**
+ * Close and release all ressource used by an Eet_Key.
+ * An reference counter prevent it from being freed until all file using it
[E-devel] Nightly build log for E17 on 2008-07-30 07:10:23 -0700
Build log for Enlightenment DR 0.17 on 2008-07-30 07:10:23 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: enna http://download.enlightenment.org/tests/logs/enna.log epdf http://download.enlightenment.org/tests/logs/epdf.log Packages with no supported build system: entice, esmart_rsvg, exorcist, python-efl, Packages skipped: camE, ecore_dbus, engage, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, Evas_Perl, evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, Packages that build OK: alarm, bling, calendar, cpu, deskshow, echo, eclair, ecore_li, ecore, edata, edb, e_dbus, edje_editor, edje, edje_viewer, edvi, eet, eflame, eflpp, efm_nav, efm_path, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emprint, emu, enesim, engrave, engycad, enhance, enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, epx, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, evolve, ewl, examine, execwatch, exhibit, exml, expedite, express, exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, iiirk, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, mpdule, net, news, notification, penguins, pesh, photo, rage, rain, screenshot, scrot, skel, slideshow, snow, taskbar, tclock, uptime, weather, winselector, wlan, Debian GNU/Linux 4.0 \n \l Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 GNU/Linux See http://download.enlightenment.org/tests/ for details. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
