Re: [E-devel] [Evil, svn trunk] autogen.sh failed on WinXP
2008/10/16 Vincent Torri [EMAIL PROTECTED]: On Thu, 16 Oct 2008, Lionel ORRY wrote: that works perfectly. Remains only the problem for autoreconf. BTW, I noticed Evil seems to be the only library in the EFL using autoreconf.. The others have autogen.sh call the autofoo tools subsequently. Maybe that would apply to Evil as well... autoreconf does what other autogen.sh does. It's sufficient for my purposes Now that the EFL are Eina-dependent, here is a _really dirty_ patch to make Eina compile on WinXP. I added guards to prevent the eina_benchmark compilation when asked because gcc threw me an internal error in eina_benchmark_init()... The dirtiest part of the patch is declaring eina_mempool_register and eina_mempool_unregister with EAPI, because it helps passing the link stage. I don't know much about the differences between .dll and .so (there must me many), but gcc was not happy with these functions prototypes. I don't know exactly how to correct that, it's just a workaround. the patch is indeed dirty :) Try with my fixes in eina, now. It compiles fine with mingw32ce. I didn't try with mingw yet If you still have link problems with eina_mempool.c, please give the exact error message, it can help me. Here is the output message : $ make make all-recursive make[1]: Entering directory `/home/liorry/eina' Making all in src make[2]: Entering directory `/home/liorry/eina/src' Making all in lib make[3]: Entering directory `/home/liorry/eina/src/lib' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/liorry/eina/src/lib' Making all in include make[3]: Entering directory `/home/liorry/eina/src/include' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/liorry/eina/src/include' Making all in modules make[3]: Entering directory `/home/liorry/eina/src/modules' Making all in mp make[4]: Entering directory `/home/liorry/eina/src/modules/mp' Making all in chained_pool make[5]: Entering directory `/home/liorry/eina/src/modules/mp/chained_pool' /bin/sh ../../../../libtool --tag=CC --tag=disable-static --mode=link gcc -std=gnu99 -O3 -s -mms-bitfields -march=i686 -no-undefined -Wl,--enable-auto-import -module -avoid-version -L/usr/local/lib -o eina_chained_mempool.la -rpath /usr/local/lib/eina/mp/ eina_chained_mempool_la-eina_chained_mempool.lo ../../../../src/lib/libeina.la -LD:/msys/1.0/local/lib -levil -ldl -lm rm -fr .libs/eina_chained_mempool.dll.a gcc -shared .libs/eina_chained_mempool_la-eina_chained_mempool.o -L/usr/local/lib ../../../../src/lib/.libs/libeina.dll.a -LD:/msys/1.0/local/lib /usr/local/lib/libevil.dll.a /usr/local/lib/libdl.dll.a -mms-bitfields -march=i686 -Wl,--enable-auto-import -o .libs/eina_chained_mempool.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/eina_chained_mempool.dll.a Creating library file: .libs/eina_chained_mempool.dll.a .libs/eina_chained_mempool_la-eina_chained_mempool.o:eina_chained_mempool.c:(.text+0x27e): undefined reference to `_eina_mempool_register' .libs/eina_chained_mempool_la-eina_chained_mempool.o:eina_chained_mempool.c:(.text+0x29e): undefined reference to `_eina_mempool_unregister' collect2: ld returned 1 exit status make[5]: *** [eina_chained_mempool.la] Error 1 make[5]: Leaving directory `/home/liorry/eina/src/modules/mp/chained_pool' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/liorry/eina/src/modules/mp' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/liorry/eina/src/modules' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/liorry/eina/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/liorry/eina' make: *** [all] Error 2 It seems like since a module uses these functions, they need to be dllexport'd or else they can't be found when linking the module. That makes sense in a way, but I don't know how the linker resolves this for .so files. I also noticed a FIXME in include/eina_inline_mempool_x: /* FIXME Do we actually need to export this functions?? */ Eina_Bool eina_mempool_register(Eina_Mempool_Backend *be); void eina_mempool_unregister(Eina_Mempool_Backend *be); Maybe that can help... Added another small patch to make Evas GLEW engine compile again (need to include glew.h before gl.h). strange, I thought i have already committed that fix. Maybe i have forgotten that. I'll fix that later. Vincent Lionel - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Copyleft-style
Gustavo Sverzut Barbieri schrieb: On Thu, Oct 16, 2008 at 7:53 PM, Michael Feiri [EMAIL PROTECTED] wrote: Now, eCos is owned by the FSF and is licensed under the GPLv2 with a linking exception that makes it completely non-viral. This exception is more powerful than the LGPL, because the LGPL does require dynamic linking or the distribution of linkable object files and additional modification and reverse engineering rights. These obligations would infect a project that would otherwise just use a non-viral GPLv2 with linker exception. So I want to ask you to please consider keeping the core EFL components and non-optional dependencies under the existing BSD-style license or consider a non-viral copyleft like the GPLv2 with a linking exception in oder to keep the EFL usable with eCos and similar free embedded operating systems (FreeRTOS and RTEMS both use GPLv2 with linking exceptions too). Dynamic linking is not an option for deeply embedded operating systems. Often we dont even have a filesystem. I really doubt this will happen. I don't have much code in Eina so I'd agree with those that have and I guess they'll not like it, as you can read in the long thread. Basically because what matters is that we want to keep a healthy community, we want your code in exchange of ours. Why can you use my code and I can NOT use yours? That's the question, the problem and the license went in to solve that. If you give us your code, we give ours. You might also consider that, as soon as somebody wants to use ecore or eet with OpenSSL, statically linking is not possible at all, because the GPL and the LGPL are incompatible to the OpenSSL license. Funny how you can shot yourself in the foot, with the choice of license. - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Copyleft-style
On Fri, 2008-10-17 at 10:14 +0200, Peter Wehrfritz wrote: Gustavo Sverzut Barbieri schrieb: On Thu, Oct 16, 2008 at 7:53 PM, Michael Feiri [EMAIL PROTECTED] wrote: Now, eCos is owned by the FSF and is licensed under the GPLv2 with a linking exception that makes it completely non-viral. This exception is more powerful than the LGPL, because the LGPL does require dynamic linking or the distribution of linkable object files and additional modification and reverse engineering rights. These obligations would infect a project that would otherwise just use a non-viral GPLv2 with linker exception. So I want to ask you to please consider keeping the core EFL components and non-optional dependencies under the existing BSD-style license or consider a non-viral copyleft like the GPLv2 with a linking exception in oder to keep the EFL usable with eCos and similar free embedded operating systems (FreeRTOS and RTEMS both use GPLv2 with linking exceptions too). Dynamic linking is not an option for deeply embedded operating systems. Often we dont even have a filesystem. I really doubt this will happen. I don't have much code in Eina so I'd agree with those that have and I guess they'll not like it, as you can read in the long thread. Basically because what matters is that we want to keep a healthy community, we want your code in exchange of ours. Why can you use my code and I can NOT use yours? That's the question, the problem and the license went in to solve that. If you give us your code, we give ours. You might also consider that, as soon as somebody wants to use ecore or eet with OpenSSL, statically linking is not possible at all, because the GPL and the LGPL are incompatible to the OpenSSL license. Funny how you can shot yourself in the foot, with the choice of license. Isn't that why GnuTLS is out there. Seems a lot of applications are switching to it, instead of to OpenSSL. - 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=100url=/ ___ 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Copyleft-style
On Fri, Oct 17, 2008 at 10:22 AM, Viktor Kojouharov [EMAIL PROTECTED] wrote: On Fri, 2008-10-17 at 10:14 +0200, Peter Wehrfritz wrote: Gustavo Sverzut Barbieri schrieb: On Thu, Oct 16, 2008 at 7:53 PM, Michael Feiri [EMAIL PROTECTED] wrote: I really doubt this will happen. I don't have much code in Eina so I'd agree with those that have and I guess they'll not like it, as you can read in the long thread. Basically because what matters is that we want to keep a healthy community, we want your code in exchange of ours. Why can you use my code and I can NOT use yours? That's the question, the problem and the license went in to solve that. If you give us your code, we give ours. You might also consider that, as soon as somebody wants to use ecore or eet with OpenSSL, statically linking is not possible at all, because the GPL and the LGPL are incompatible to the OpenSSL license. Funny how you can shot yourself in the foot, with the choice of license. Isn't that why GnuTLS is out there. Seems a lot of applications are switching to it, instead of to OpenSSL. GnuTLS would be a good move for us. Leting people build GPL apps on top of our software and use a lighter lib (around 3MB for openssl and 1MB for Gnutls). I would add that GnuTLS offer a better experience in cross compiling thanks to the autotools (Yeah, I really said that :-)). Checking their documentation, it seems they provide every thing we need for eet and ecore. -- 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Copyleft-style
Peter Wehrfritz wrote: Gustavo Sverzut Barbieri schrieb: On Thu, Oct 16, 2008 at 7:53 PM, Michael Feiri [EMAIL PROTECTED] wrote: Now, eCos is owned by the FSF and is licensed under the GPLv2 with a linking exception that makes it completely non-viral. This exception is more powerful than the LGPL, because the LGPL does require dynamic linking or the distribution of linkable object files and additional modification and reverse engineering rights. These obligations would infect a project that would otherwise just use a non-viral GPLv2 with linker exception. So I want to ask you to please consider keeping the core EFL components and non-optional dependencies under the existing BSD-style license or consider a non-viral copyleft like the GPLv2 with a linking exception in oder to keep the EFL usable with eCos and similar free embedded operating systems (FreeRTOS and RTEMS both use GPLv2 with linking exceptions too). Dynamic linking is not an option for deeply embedded operating systems. Often we dont even have a filesystem. I really doubt this will happen. I don't have much code in Eina so I'd agree with those that have and I guess they'll not like it, as you can read in the long thread. Basically because what matters is that we want to keep a healthy community, we want your code in exchange of ours. Why can you use my code and I can NOT use yours? That's the question, the problem and the license went in to solve that. If you give us your code, we give ours. You might also consider that, as soon as somebody wants to use ecore or eet with OpenSSL, statically linking is not possible at all, because the GPL and the LGPL are incompatible to the OpenSSL license. Funny how you can shot yourself in the foot, with the choice of license. Yes, huge gaping holes in what used to be rapidly advancing feet. But you're right about some things being funny, like secret projects somewhere suddenly being inconvenienced, or worse still, the world's last and only hope for 'free' software being developed for use on the iPhone.. thrown away! Surely that alone should motivate every developer everywhere to move all their code to a bsd license. :) Click for free quote on refinancing your mortgage. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3m3eQ3WnXY6DOHOUFhNk7OknIeFmZig95u6Q6WJ9qVZF8h7y/ - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] IMLIB2 ported to mingw+msys
On Thu, 16 Oct 2008, Kim Woelders wrote: If all that's needed is included in the patch I think it's a bit much to have to depend on another (unreleased) library. on the other hand, it's a windows port, so I don't think that there are much people who will compile it. What is expected by Windows users is a binary + dll. By release, you mean a 1.* one ? If so, would you have objections that I add Evil as a dependency ? I plan to have an Evil release in some months. Vincent - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Fw: Re: Copyleft-style
(forgot AUTHORS in cc list) PLEASE REPLY (authors on CC list). yes or no to adding static linking exception below? On Fri, 17 Oct 2008 00:53:29 +0200 Michael Feiri [EMAIL PROTECTED] babbled: this got debated to hell. the alternative was going to be watching developers leave - ones wanting to add in better code but only wanting to do so if they know their code will be free and improvements to it given back. if we added the static linking exception - which imho would not violate the spirit of the LGPL, would this be good enough? (nb - if apple decide to place all these nasty nasty nasty restrictions on developers and applications - all the best to them, but i know i have zero interest in becoming part of that world as long as apple basically say you do just what we say, what we want, and if we don't like you we'll just ban your app from the platform because you may possibly compete with us or be the wrong shade of pink for steve jobs). i definitely buy the ecos (static linking) argument. i've explicitly cc'd all the AUTHORS for eina. do you guys agree to adding an ecos-style static linking exception (here it is for you guys): ...As a special exception, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other works to produce a work based on this file, this file does not by itself cause the resulting work to be covered by the GNU General Public License. However the source code for this file must still be made available in accordance with section (3) of the GNU General Public License. This exception does not invalidate any other reasons why a work based on this file might be covered by the GNU General Public License On monday, starting with revision 36622, all vital EFL components have been configured to depend on copylefted code (eina is licensed under LGPLv2.1). This is unfortunate, as it renders the existing BSD-style license agreement essentially worthless. It is especially unfortunate as the EFL seems to be unique as the only successful GUI environment under a BSD-style license. I have used Evas as a component in a proof-of-concept for an embedded project using the eCos operating system. No patches or other information have been published yet, because the project is not yet released. But I do expect to have patches for EFL ready upon release in order to avoid the advertisement clause. Now, eCos is owned by the FSF and is licensed under the GPLv2 with a linking exception that makes it completely non-viral. This exception is more powerful than the LGPL, because the LGPL does require dynamic linking or the distribution of linkable object files and additional modification and reverse engineering rights. These obligations would infect a project that would otherwise just use a non-viral GPLv2 with linker exception. So I want to ask you to please consider keeping the core EFL components and non-optional dependencies under the existing BSD-style license or consider a non-viral copyleft like the GPLv2 with a linking exception in oder to keep the EFL usable with eCos and similar free embedded operating systems (FreeRTOS and RTEMS both use GPLv2 with linking exceptions too). Dynamic linking is not an option for deeply embedded operating systems. Often we dont even have a filesystem. Additionally I might mention that the BSD-style license of the EFL could mean that the EFL might technically be the only serious option for a free 3rd party GUI library on things like the iPhone. Dynamic linking does seem to exist on this platform but things like forced codesigning, bans on externally loadable code, and restrictions on reverse engineering and modification rights make the use of copylefted code questionable at best. MfG, Michael - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net
[E-devel] svn pre-commit error
suddenly I'm not able to commit files in svn anymore :( my last commit was 4 days ago, now when I try to commit something I get this error: 'pre-commit' hook failed with error output: but unfotunately the message ends here, there is no error output actually. -- Massimo Maiurana massimoatragusa.linux.it http://massimo.solira.org GPG keyID #7044D601 Articolo 33 - [...]Enti e privati hanno il diritto di istituire scuole ed istituti di educazione, senza oneri per lo Stato.[...] - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] svn pre-commit error
You are trying to commit po files? Massimo Maiurana wrote: suddenly I'm not able to commit files in svn anymore :( my last commit was 4 days ago, now when I try to commit something I get this error: 'pre-commit' hook failed with error output: but unfotunately the message ends here, there is no error output actually. - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] svn pre-commit error
Nick Hughart, il 17/10/2008 21:42, scrisse: You are trying to commit po files? I'm trying to commit these two files, one of them is a po file: - trunk/e/po/fr.po - trunk/E-MODULES-EXTRA/diskio/module.desktop.in even the files I committed 4 days ago without errors were po files. -- Massimo Maiurana massimoatragusa.linux.it http://massimo.solira.org GPG keyID #7044D601 Articolo 33 - [...]Enti e privati hanno il diritto di istituire scuole ed istituti di educazione, senza oneri per lo Stato.[...] - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] svn pre-commit error
Massimo Maiurana wrote: Nick Hughart, il 17/10/2008 21:42, scrisse: You are trying to commit po files? I'm trying to commit these two files, one of them is a po file: - trunk/e/po/fr.po - trunk/E-MODULES-EXTRA/diskio/module.desktop.in even the files I committed 4 days ago without errors were po files. KainX recently made a modification to the hook so that people wouldn't be flooded with po file updates, might have broken commits involving po files though :/ - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] eina : use lstat instead of d_type
hi
eina only build on linux/BSD OS because it's use d_type . I try to
create a patch to use lstat instead d_type but i have big problem with
C :)
Does someone can tell me if this patch is ok or not ?
thanks
$ gdiff -Naur e17_src/eina/src/lib/eina_file.c eina_file.c
--- e17_src/eina/src/lib/eina_file.c2008-10-17 10:54:13.008637731 +0200
+++ eina_file.c 2008-10-17 22:40:00.648011565 +0200
@@ -117,6 +117,7 @@
#ifndef _WIN32
struct dirent *de;
DIR *d;
+ struct stat statbuf;
if (!cb) return EINA_FALSE;
@@ -139,7 +140,7 @@
strcat(path, /);
strcat(path, de-d_name);
- if (de-d_type == DT_UNKNOWN) {
+ if (lstat(de-d_name, statbuf) == -1) {
struct stat st;
if (stat(path, st))
@@ -147,8 +148,10 @@
if (!S_ISDIR(st.st_mode))
continue ;
- } else if (de-d_type != DT_DIR) {
- continue ;
+ } else {
+ if (!S_ISDIR(statbuf.st_mode)) {
+ continue ;
+ }
}
eina_file_dir_list(path, recursive, cb, data);
-
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=100url=/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] IMLIB2 ported to mingw+msys
On Friday, 17 October 2008, at 14:02:56 (+0200), Vincent Torri wrote: By release, you mean a 1.* one ? If so, would you have objections that I add Evil as a dependency ? I plan to have an Evil release in some months. As long as it's only a dependency on Windows platforms. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- I don't know what will be used in the next world war, but the fourth will be fought with stones. -- Albert Einstein - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] svn pre-commit error
Michael Jennings, il 17/10/2008 22:53, scrisse: On Friday, 17 October 2008, at 21:16:07 (+0200), Massimo Maiurana wrote: suddenly I'm not able to commit files in svn anymore :( my last commit was 4 days ago, now when I try to commit something I get this error: 'pre-commit' hook failed with error output: but unfotunately the message ends here, there is no error output actually. Supply a commit message. ok, supplying a log message it works, thanks :) however, wouldn't it be better to put an error output like missing log message? that way I could have understood the problem by myself... -- Massimo Maiurana massimoatragusa.linux.it http://massimo.solira.org GPG keyID #7044D601 Articolo 33 - [...]Enti e privati hanno il diritto di istituire scuole ed istituti di educazione, senza oneri per lo Stato.[...] - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Copyleft-style
Carsten Haitzler (The Rasterman) schrieb: On Fri, 17 Oct 2008 00:53:29 +0200 Michael Feiri [EMAIL PROTECTED] babbled: this got debated to hell. the alternative was going to be watching developers leave - ones wanting to add in better code but only wanting to do so if they know their code will be free and improvements to it given back. if we added the static linking exception - which imho would not violate the spirit of the LGPL, would this be good enough? (L)GPL with a linking exception would be a good solution. MfG, Michael - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] IMLIB2 ported to mingw+msys
On Fri, 17 Oct 2008 14:02:56 +0200, Vincent Torri [EMAIL PROTECTED] wrote: On Thu, 16 Oct 2008, Kim Woelders wrote: If all that's needed is included in the patch I think it's a bit much to have to depend on another (unreleased) library. on the other hand, it's a windows port, so I don't think that there are much people who will compile it. What is expected by Windows users is a binary + dll. By release, you mean a 1.* one ? Yes, that is what I meant. One that is announced as released, and is maintained and bugfixed. I assume stable API is not an issue in this particular case. Anyway, if this only affects windows targets I guess I shouldn't care too much. If so, would you have objections that I add Evil as a dependency ? I plan to have an Evil release in some months. Please do not do this before 1.4.2 out. /Kim - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] svn pre-commit error
On Friday, 17 October 2008, at 23:27:22 (+0200), Massimo Maiurana wrote: however, wouldn't it be better to put an error output like missing log message? that way I could have understood the problem by myself... I'm not sure why it wasn't done that way...but it is now. :-) Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- A slipping gear could let your M203 grenade launcher fire when you least expect it. That would make you quite unpopular in what's left of your unit. -- In the August 1993 issue, page 9, of PS magazine - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Copyleft-style
Gustavo Sverzut Barbieri schrieb: On Thu, Oct 16, 2008 at 7:53 PM, Michael Feiri [EMAIL PROTECTED] wrote: On monday, starting with revision 36622, all vital EFL components have been configured to depend on copylefted code (eina is licensed under LGPLv2.1). This is unfortunate, as it renders the existing BSD-style license agreement essentially worthless. It is especially unfortunate as the EFL seems to be unique as the only successful GUI environment under a BSD-style license. it's not worthless, it still let you copy, modify and no need to redistribute all other pieces. You can even do that and remove the eina dependency and replace it with your own data libraries. You're also free to keep using the pre-eina version. I didnt plan to just cannibalize code but rather hoped to eventually port the entire core EFL stack to eCos. I know I could just fork, but I was hoping to avoid that. I have used Evas as a component in a proof-of-concept for an embedded project using the eCos operating system. No patches or other information have been published yet, because the project is not yet released. But I do expect to have patches for EFL ready upon release in order to avoid the advertisement clause. note that while you don't release this to outer world you have no issues. I mean, if you use it inside your company for demo purposes, you can distribute code to yourselves and no problem. It's just a problem when you send it to third parties. Now, eCos is owned by the FSF and is licensed under the GPLv2 with a linking exception that makes it completely non-viral. This exception is more powerful than the LGPL, because the LGPL does require dynamic linking or the distribution of linkable object files and additional modification and reverse engineering rights. These obligations would infect a project that would otherwise just use a non-viral GPLv2 with linker exception. So I want to ask you to please consider keeping the core EFL components and non-optional dependencies under the existing BSD-style license or consider a non-viral copyleft like the GPLv2 with a linking exception in oder to keep the EFL usable with eCos and similar free embedded operating systems (FreeRTOS and RTEMS both use GPLv2 with linking exceptions too). Dynamic linking is not an option for deeply embedded operating systems. Often we dont even have a filesystem. I really doubt this will happen. I don't have much code in Eina so I'd agree with those that have and I guess they'll not like it, as you can read in the long thread. Basically because what matters is that we want to keep a healthy community, we want your code in exchange of ours. Why can you use my code and I can NOT use yours? That's the question, the problem and the license went in to solve that. If you give us your code, we give ours. In my case the mix of 4-clause and 3-clause BSD in the existing license was sufficient incentive for me to plan to contribute code back. I do know about the different motivations and interpretations of freedom in the GNU and BSD camps. Thats fine. No need to discuss that. I got the impression that in licensing - end it Raster expressed the hope for BSD and LGPL to just live together in peace. Unfortunately in the specific case of static linking this seems to require the mentioned linking exception. Additionally I might mention that the BSD-style license of the EFL could mean that the EFL might technically be the only serious option for a free 3rd party GUI library on things like the iPhone. Dynamic linking does seem to exist on this platform but things like forced codesigning, bans on externally loadable code, and restrictions on reverse engineering and modification rights make the use of copylefted code questionable at best. I strongly disagree here. The problem is not about the library, dynamic linking or even licensing, it's about the platform. And I really doubt someone using EFL directly on iPhone, it have its own set of libraries, which is very complete and optimized by the way. We don't have that much apps to be ported, so not much point here. Valid points. I still see an opportunity for a cross platform GUI library written in plain C though. Anyway. I wish I didnt mention this particular example as it seems to generate mostly irrational hostility and distraction. Right now I really just care about static linking. MfG, Michael - 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=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
