Re: [E-devel] Announce: EFL 1.7.2 release and E17 ALPHA 5 release
On Wed, Nov 28, 2012 at 01:16:19AM +0900, Carsten Haitzler wrote: On Tue, 27 Nov 2012 16:15:14 +0200 Raphael Kubo da Costa raphael.kubo.da.co...@intel.com said: Luis Felipe Strano Moraes luis.str...@gmail.com writes: We're organizing a new Release Team in order to help out with this entire process, and would like to call out to everyone interested in helping out to please join the enlightenment-releasehttps://lists.sourceforge.net/lists/listinfo/enlightenment-releasemailing list. People who are actively working on packaging or who have interest in it are specially welcome. For the old farts who prefer to use NNTP, the gmane.comp.window-managers.enlightenment.release has been created (it also serves as a mail archive): http://dir.gmane.org/gmane.comp.window-managers.enlightenment.release wow... newsgroup! that brings back memories of trn and tin... :) Good memories :) -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Announce] E17 Alpha Release
On Mon, Nov 05, 2012 at 03:49:10PM +, Michael Blumenkrantz wrote: At the EFL Dev Day during a talk by Jorge turran Zapata, decisions were made. These decisions resulted in actions which ended up breaking my gmail (no joke), possibly foreshadowing the breaking of the world later on. This is the announcement for the ALPHA release of Enlightenment DR 0.17. E17 is a desktop environment that's been under development for a couple years, and it's finally at the point where we're happy enough with it to do an alpha release. Conveniently, this comes mere hours before I will be giving a presentation at LinuxCon wherein I will announce the release schedule for E17. http://download.enlightenment.org/releases/enlightenment-0.17.0-alpha.tar.gz http://download.enlightenment.org/releases/enlightenment-0.17.0-alpha.tar.bz2 The end is near. Great! -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] resolve eet build failure
On Thu, Sep 10, 2009 at 10:04:15AM +0200, Albin Tonnerre wrote: On Thu, 10 Sep 2009 15:42 +1000, Simon Horman wrote : As reported in track ticket 377 (amongst other things), eet seems to fail to build (on Debian). # svn checkout FOO/eet # cd eet # ./autogen.sh # make [snip] libtool: link: gcc -std=gnu99 -Wall -O2 -fomit-frame-pointer -pipe -Wl,--as-needed -o .libs/eet eet-eet_main.o ../../src/lib/.libs/libeet.so ../../src/lib/.libs/libeet.so: undefined reference to `clock_gettime' ../../src/lib/.libs/libeet.so: undefined reference to `dlsym' ../../src/lib/.libs/libeet.so: undefined reference to `dlerror' ../../src/lib/.libs/libeet.so: undefined reference to `pthread_spin_lock' ../../src/lib/.libs/libeet.so: undefined reference to `pthread_spin_unlock' ../../src/lib/.libs/libeet.so: undefined reference to `pthread_spin_init' ../../src/lib/.libs/libeet.so: undefined reference to `dladdr' ../../src/lib/.libs/libeet.so: undefined reference to `pthread_spin_destroy' ../../src/lib/.libs/libeet.so: undefined reference to `dlopen' ../../src/lib/.libs/libeet.so: undefined reference to `dlclose' collect2: ld returned 1 exit status make[3]: *** [eet] Error 1 make[3]: Leaving directory `/home/horms/projects/e/svn/trunk/eet/src/bin' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/horms/projects/e/svn/trunk/eet/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/horms/projects/e/svn/trunk/eet' make: *** [all] Error 2 A simple solution seems to be to link libeet against ldl and lrt as follows. Is this acceptable? That looks *a lot* like one of eet's dependencies is missing proper linking, rather as eet itself - as it doesn't have any pthread code nor dlopen code. Have you checked whether eina is correctly linked against libdl and libpthread ? Good thinking. I'll try looking into that. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [patch] esmart: Add autogen.sh to dist tarball
On Wed, Sep 09, 2009 at 09:30:24AM +0200, Albin Tonnerre wrote: On Wed, 09 Sep 2009 09:24 +1000, Simon Horman wrote : Is the following appropriate? - Subject: Add autogen.sh to dist tarball autogen.sh is used by the debian packaging so it seems appropriate to include it in the dist tarball Either you're packaging from SVN and therefore don't need it to be part of the dist tarball, or you're packaging from the snapshots at download.enlightenment.org (or snapshots you generated) and then your packaging should be fixed to use directly ./configure instead of configure.sh. Is there an actual use case I'm missing, for which this change would be required? Thanks for filling me in on the expected usage. I was thinking of the case where you want to test what is in SVN by: 1) creating a tarball 2) building a debian package from that tarball after unpacking is and manually copying over the debian/ directory from SVN. But if thats not valid, I'll stop doing it. When you say fixed to use ./configure directly, when and how does that occur? I agree that calling ./configure is preferable when building Debian packages. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [patch] esmart: Add autogen.sh to dist tarball
On Thu, Sep 10, 2009 at 10:46:54AM +1000, Carsten Haitzler wrote: On Thu, 10 Sep 2009 09:50:04 +1000 Simon Horman ho...@verge.net.au said: On Wed, Sep 09, 2009 at 09:30:24AM +0200, Albin Tonnerre wrote: On Wed, 09 Sep 2009 09:24 +1000, Simon Horman wrote : Is the following appropriate? - Subject: Add autogen.sh to dist tarball autogen.sh is used by the debian packaging so it seems appropriate to include it in the dist tarball Either you're packaging from SVN and therefore don't need it to be part of the dist tarball, or you're packaging from the snapshots at download.enlightenment.org (or snapshots you generated) and then your packaging should be fixed to use directly ./configure instead of configure.sh. Is there an actual use case I'm missing, for which this change would be required? Thanks for filling me in on the expected usage. actually. alibin is wrong (sorry!) autogen's do get packaged. look at existing efl. we put it in so if u get a tarball u CAN easily modify the configure.ac, Makefile.am's etc. and re-generate the autofoo. the script will be there with all the magic. not everyone will want or need to do this from a tarball dist - but it dos happen. people patching packages are often the ones using it. so it's not valid. it's an omission in the esmart build foo. :) (even if albin was right - eet, evas, elementary, edje, ... etc. all include autogen.sh in their EXTRA_DIST, so it'd go in for consistency sake. it's goo to have everything in svn have consistent autofoo files and work the same way. it makes everything hav the same bug o everything is right. not some things buggy, some not, in terms of autofoo usage/structure, so if u do find a bug/issue - u can know that fixing it everywhere else is trivial) Ok, I should have pointed out in the beginning that I really just wanted to make things consistent. With that in mind I'll commit my change. It can always be changed if in the future it is decided to consistently do something else. [snip] -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] RFC eina inlist, list
On Thu, Sep 10, 2009 at 10:53:17AM +1000, Carsten Haitzler wrote: On Tue, 8 Sep 2009 20:52:39 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: you've already put my word in on this. i go the accounting way. 1. it is consistent with eina_list. 2. can be extended beyond last and include count and many other things. 3. doesn't change inlist struct size to be bigger (tho we dont win on it being smaller). 4. doesnt play evil games. (using low-order bits in pointers is wrong imho. i've sen this game played before (using high order bits) and then it com crashing down on peoples heads when suddenly those used bits become relevant. using those bits will also require instruction overhead of masking them out always before use. so you lose on the code simplicity and speed side, just to save 4 bytes (or 8 on 64bit) per inlist instance. it's not worth it. it is possible also in future allocations no longer are limited to word boundaries and allocs do use those bits, thus removing them from our use and requiring another solution. Does anyone know if the issues related to using the lower bits of pointers architecture-specific, libc-specific or both? I was pondering this recently in relation to a different project. I know that they use this technique in the Linux kernel. But obviously they have quite a lot of control over what their memory addresses look like in terms of alignment and thus unused bits. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] resolve eet build failure
As reported in track ticket 377 (amongst other things), eet seems to fail to build (on Debian). # svn checkout FOO/eet # cd eet # ./autogen.sh # make [snip] libtool: link: gcc -std=gnu99 -Wall -O2 -fomit-frame-pointer -pipe -Wl,--as-needed -o .libs/eet eet-eet_main.o ../../src/lib/.libs/libeet.so ../../src/lib/.libs/libeet.so: undefined reference to `clock_gettime' ../../src/lib/.libs/libeet.so: undefined reference to `dlsym' ../../src/lib/.libs/libeet.so: undefined reference to `dlerror' ../../src/lib/.libs/libeet.so: undefined reference to `pthread_spin_lock' ../../src/lib/.libs/libeet.so: undefined reference to `pthread_spin_unlock' ../../src/lib/.libs/libeet.so: undefined reference to `pthread_spin_init' ../../src/lib/.libs/libeet.so: undefined reference to `dladdr' ../../src/lib/.libs/libeet.so: undefined reference to `pthread_spin_destroy' ../../src/lib/.libs/libeet.so: undefined reference to `dlopen' ../../src/lib/.libs/libeet.so: undefined reference to `dlclose' collect2: ld returned 1 exit status make[3]: *** [eet] Error 1 make[3]: Leaving directory `/home/horms/projects/e/svn/trunk/eet/src/bin' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/horms/projects/e/svn/trunk/eet/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/horms/projects/e/svn/trunk/eet' make: *** [all] Error 2 A simple solution seems to be to link libeet against ldl and lrt as follows. Is this acceptable? --- eet.orig/src/lib/Makefile.am2009-09-10 15:40:32.0 +1000 +++ eet/src/lib/Makefile.am 2009-09-10 15:42:13.0 +1000 @@ -30,7 +30,7 @@ eet_node.c \ eet_utils.c libeet_la_CFLAGS = @EET_CFLAGS@ @DEBUG_CFLAGS@ -libeet_la_LIBADD = @GNUTLS_LIBS@ @OPENSSL_LIBS@ @EFL_COVERAGE_LIBS@ @EET_LIBS@ @EINA_LIBS@ @EVIL_LIBS@ -lz -ljpeg -lm +libeet_la_LIBADD = @GNUTLS_LIBS@ @OPENSSL_LIBS@ @EFL_COVERAGE_LIBS@ @EET_LIBS@ @EINA_LIBS@ @EVIL_LIBS@ -lz -ljpeg -lm -ldl -lrt libeet_la_LDFLAGS = -no-undefined @lt_enable_auto_import@ -version-info @version_info@ @release_info@ EXTRA_DIST = Eet_private.h -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [patch] esmart: Add autogen.sh to dist tarball
Is the following appropriate? - Subject: Add autogen.sh to dist tarball autogen.sh is used by the debian packaging so it seems appropriate to include it in the dist tarball Index: esmart/Makefile.am === --- esmart.orig/Makefile.am 2009-09-09 09:12:57.0 +1000 +++ esmart/Makefile.am 2009-09-09 09:13:03.0 +1000 @@ -18,7 +18,7 @@ EXTRA_DIST = README AUTHORS COPYING esma esmart_text_entry.pc.in \ esmart_thumb.pc.in \ esmart_trans_x11.pc.in \ -esmart_xpixmap.pc.in +esmart_xpixmap.pc.in autogen.sh pkgconfigdir = $(libdir)/pkgconfig -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] moving things to OLD/BROKEN
On Wed, Jun 17, 2009 at 03:14:04PM -0300, Gustavo Sverzut Barbieri wrote: Done, see http://trac.enlightenment.org/e/changeset/41086 On Tue, Jun 9, 2009 at 2:01 PM, Gustavo Sverzut Barbieribarbi...@profusion.mobi wrote: Hi all, I want to move the following projects to BROKEN/OLD as they're one of them: - edje_viewer (edje_player/edje_editor work better) - elicit (users of it? if so, remove imlib2, ecore-config and probably esmart dependencies -- otherwise it will be moved) - emphasis (remove ecore-config, or it will be moved) - enhance (not being maintained and not being used AFAIK) - enity (not being maintained and not being used AFAIK) - ephoto (being replaced by new version soon) - epsilon (replaced by ethumb) - etk_extra (not being maintained and not being used AFAIK) - evolve (not being maintained and not being used AFAIK) - exhibit (not being maintained) the following all fit under not being maintained: - MISC/eeh - MISC/eflame - MISC/eke - MISC/elapse - MISC/elogin - MISC/embrace - MISC/engage - MISC/enthrall - MISC/envision - MISC/epbb - MISC/eplay - MISC/eplayer - MISC/equate - MISC/erss - MISC/esmart_rsvg - MISC/ewler - MISC/gevas2 - MISC/gevas-examples - MISC/ipaq - MISC/lvs-gui - MISC/nexus I still maintain nexus in that directory, its just that it seldom needs changes. - MISC/notgame - MISC/pesh - MISC/retina - MISC/slets - MISC/webcam - MISC/webpictures -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] moving things to OLD/BROKEN
On Wed, Jun 17, 2009 at 10:14:36PM -0300, Gustavo Sverzut Barbieri wrote: On Wed, Jun 17, 2009 at 7:50 PM, Simon Hormanho...@verge.net.au wrote: On Wed, Jun 17, 2009 at 03:14:04PM -0300, Gustavo Sverzut Barbieri wrote: Done, see http://trac.enlightenment.org/e/changeset/41086 On Tue, Jun 9, 2009 at 2:01 PM, Gustavo Sverzut Barbieribarbi...@profusion.mobi wrote: Hi all, I want to move the following projects to BROKEN/OLD as they're one of them: - edje_viewer (edje_player/edje_editor work better) - elicit (users of it? if so, remove imlib2, ecore-config and probably esmart dependencies -- otherwise it will be moved) - emphasis (remove ecore-config, or it will be moved) - enhance (not being maintained and not being used AFAIK) - enity (not being maintained and not being used AFAIK) - ephoto (being replaced by new version soon) - epsilon (replaced by ethumb) - etk_extra (not being maintained and not being used AFAIK) - evolve (not being maintained and not being used AFAIK) - exhibit (not being maintained) the following all fit under not being maintained: - MISC/eeh - MISC/eflame - MISC/eke - MISC/elapse - MISC/elogin - MISC/embrace - MISC/engage - MISC/enthrall - MISC/envision - MISC/epbb - MISC/eplay - MISC/eplayer - MISC/equate - MISC/erss - MISC/esmart_rsvg - MISC/ewler - MISC/gevas2 - MISC/gevas-examples - MISC/ipaq - MISC/lvs-gui - MISC/nexus I still maintain nexus in that directory, its just that it seldom needs changes. sorry! :-) KainX already fixed it. Thanks :-) -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto/eina turran
On Fri, Aug 08, 2008 at 12:51:18PM -0300, Gustavo Sverzut Barbieri wrote:
On Fri, Aug 8, 2008 at 7:39 AM, Enlightenment CVS
[EMAIL PROTECTED] wrote:
+EAPI void eina_error_print(Eina_Error_Level level, const char *file,
const char *fnc, int line, const char *fmt, ...)
{
va_list args;
va_start(args, fmt);
- _error_print(level, file, fnc, line, fmt, args);
+ if (level = _error_level)
+ _print_cb(level, file, fnc, line, fmt, _print_cb_data,
args);
va_end(args);
+}
Let's try to avoid this useless nesting and also making it more
optimized, in this case, by using:
if (premature-exit-condition)
return;
IMHO, if possible exiting early, as you suggest, almost always leads to
cleaner code.
-
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] Time-based releases
On Wed, Aug 06, 2008 at 12:21:28PM -0400, Thiago Marcos P. Santos wrote: Git can also improve the patches quality, because you can work offline (i.e. reorder, redo, refactory, etc your commit) and when you think that everything is perfect, send the patchs. With CVS you will need something like quilt in order to do this. I agree with your point, its all about the workflow. However, if you are in a situation where there can be several cycles of posting and reviewing patches before they are merged, then a tool like quilt can be quite useful even if you are using something like git or hg. - 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] [RFC] EET crypto and signature support.
On Tue, Jun 24, 2008 at 03:27:30PM +1000, Carsten Haitzler wrote: On Tue, 24 Jun 2008 00:48:04 -0400 Simon Horman [EMAIL PROTECTED] babbled: I'm not exactly sure what you are planing to push into and pull out of this API, but it might be more sensible to provide the key on open. And then use a scheme like CBC to encode a stream of data until it is done. Then close. Or in other words; start(); add_data()...; finish(); as eet files can store multiple (independent) data segments - addressed by key strings (like a tar.gz with multilple files in it) it makes the most sense for the key to be provided along with reading/writing a specific data segment - no? If you just want to encrypt/unencrypt things at the granularity of what is accessed using read/write, then yes, what you suggested makes good sense. The API that I was getting at would work well in situations where an encrypted chunk of data would be built up using muiltiple writes(), presumably because its either very large or isn't all available in one hit for some reason. That doesn't seem to be the case here. Having a pool of registered keys might make sense if it is envisaged that more than one might be used at a time - though not on the same set of data. makes sense if we consider the whole file encrypted, but as such why limit it to a set of keys you have to set up in advance (other than performance)? :) Cedric made a subsequent post on this. With regards do zeroing RAM, that is a good idea. But its really all a bit moot if the memory is swappable. sure - though as such it would massively reduce the likelihood of inadvertent passkey trails in core dumps etc. swap we can't do anything about - but if you copy the key, use it and derivative data really fast them nuke everything chances of it being found later by mistake are lower. it's definitely not a solution, but a risk mitigation at any rate. if you have access to the memory space of a process to be able to do this it's normally game over anyway, but there is not much we can do there beyond mlock()... and then we're in root-only land. Agreed. Though it may be worth using mlock() if the euid happens to be 0. -- Horms - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] EET crypto and signature support.
On Thu, Jun 26, 2008 at 02:22:00PM +0200, Cedric BAIL wrote: On Tue, Jun 24, 2008 at 7:27 AM, The Rasterman Carsten Haitzler [EMAIL PROTECTED] wrote: On Tue, 24 Jun 2008 00:48:04 -0400 Simon Horman [EMAIL PROTECTED] babbled: I'm not exactly sure what you are planing to push into and pull out of this API, but it might be more sensible to provide the key on open. And then use a scheme like CBC to encode a stream of data until it is done. Then close. Or in other words; start(); add_data()...; finish(); as eet files can store multiple (independent) data segments - addressed by key strings (like a tar.gz with multilple files in it) it makes the most sense for the key to be provided along with reading/writing a specific data segment - no? Having a pool of registered keys might make sense if it is envisaged that more than one might be used at a time - though not on the same set of data. makes sense if we consider the whole file encrypted, but as such why limit it to a set of keys you have to set up in advance (other than performance)? :) The idea of setting up the key in advance give us the possibility to set them outside of the direct user of the eet file. We can cypher an edje collection and without any modification to edje library use it. Same goes with any user of eet, no need to change it. Only the apps that want to use this feature will need a change (and of course they will need it as they need a way to provide the key). Another issue may be if keys need to be unlocked using a passphrase or other wise initialised in an interactive or expensive way. If that were the case it would make sense to initialise each key once per session rather than each time a read() or write() was performed. Cedric, with regards to your initial question of using an existing scheme or creating a new one. I would suggest the former as getting such scheme right can be tricky, so its usually better to use established methods. -- Horms - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [RFC] EET crypto and signature support.
On Tue, Jun 24, 2008 at 02:32:22AM +1000, Carsten Haitzler wrote: On Mon, 16 Jun 2008 15:33:23 +0200 Cedric BAIL [EMAIL PROTECTED] babbled: Hi all, I want to add crypto and signature support inside EET. This could help us provide some secure way to store password for example or the possibility to add signature to theme. The first step before doing this, is the need to agree what kind of feature we want, what will be the dependency introduced by this and if they should be optionnal. For crypto, we could have two possibilities, or we cypher the entire EET file or just an Eet_File_Node. Cyphering an entire file is perhaps not what we want, I don't thing we need to cypher all image, data and agreed. if you want whole-file encryption i am sure there are more transparent ways to get it (a vfs layer for examlpe). one day streams. I believe that just cyphering an Eet_File_Node is enough. We have still 31 bits available in the flags field. We could use 8bits of this field to define a key index that will be provide at run time to the right Eet_File. For this we will need the following API : EAPI Eet_Key *eet_crypt_key_new(const char *key); EAPI void eet_crypt_key_free(Eet_Key *key); EAPI int eet_crypt_key_define(Eet_File *ef, Eet_Key *key, unsigned char index); EAPI int eet_crypt_key_set(Eet_File *ef, const char *name, unsigned char index); EAPI int eet_crypt_key_get(Eet_File *ef, const char *name); I think we could also provide : EAPI void *eet_crypt_data(Eet_Key *key, void *data, int length); EAPI void *eet_uncrypt_data(Eet_Key *key, void *data, int length); and manipulate cyphered eet data. Now for signature support, I think we don't need to sign per Eet_File_Node, but only for the eet file. On this topic I don't know if we need to have our own way of signing our data (adding signature a bunch of signature at the end of the eet file or if we should use any known schem. Perhaps it depend on the crypto library we decide to use. i can't much comment - i'm no expert on this :( it's a subject area i have never really paid much attention to. On this topic, I believe we have two choice, libtomcrypt (http://libtom.org/?page=featuresnewsitems=5whatfile=crypt) and openssl. My opinion on this subject is certainly biased as I already use libtomcrypt, but it's a small, simple and easy to port library. I believe we should make this dependency optional (if eet is compiled without crypto support all function call requiring it will just cleanly fail). agree with it being optional. agree with them failing if not compiled in. i lean to openssl myself - or even gnutls. i know little of libmcrypt. as above. i'm no expert. what i will say. the whole key index thing looks odd to me. we are going to just deal with tiny bits of encrypted data here, so efficiency is not so important. why not simply provide a simplistic EAPI void *eet_crypt_read(Eet_File *ef, const char *name, const char *key, int *size_ret); EAPI int eet_crypt_write(Eet_File *ef, const char *name, const char *key, const void *data, int size, int compress); ? as such the data is encrypted given a specific passphrase/key and stored. that key is needed for decryption (if not given - we can either return NUL or just garbage. up to us). the important bits here are that without the key - the item cannot (sanely) be decrypted. (sure given 192332 years and enough compute power to run that long...). so from the key you generate a salt and then encode/decode with that. the important bit is making sure that key is not left around anywhere. any copies of it in ram are nulled out as soon as they are not used anymore etc. etc. - at least as far as eet is concerned. null out any useful intermediate data too. i dont see why we need to go define limited fixed set of keys per file? just provide the key on read/write? I'm not exactly sure what you are planing to push into and pull out of this API, but it might be more sensible to provide the key on open. And then use a scheme like CBC to encode a stream of data until it is done. Then close. Or in other words; start(); add_data()...; finish(); Having a pool of registered keys might make sense if it is envisaged that more than one might be used at a time - though not on the same set of data. With regards do zeroing RAM, that is a good idea. But its really all a bit moot if the memory is swappable. So guys, what's your opinion on this subject ? -- Cedric BAIL - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list
Re: [E-devel] E CVS: libs/eet horms
On Wed, Jun 11, 2008 at 01:40:37PM +0800, Carsten Haitzler wrote: On Wed, 11 Jun 2008 15:12:21 +1000 Simon Horman [EMAIL PROTECTED] babbled: From reading Raster's comments, I gleen that the idea is basically to leave the debian/ directroes in CVS, generally speaking containing a changelog.in but no changelog. And not distributing the debian/ directory in the tarball. For my own usage (sporadic as it is), this is fine. It would just be an incredible choore to have to go and recreate all the debian/ directories by hand. But if the data is in CVS, thats fine. Presumably there aren't any objections to making (minor) modifications to it such as fixing up build dependancies. no objections - as long as it doesnt get into dist tarballs - the debian guys are happy :) Understood. -- Horms - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/eet horms
Ok, please feel free to revert the change. But how does debian/changelog get created? On Tue, Jun 10, 2008 at 11:21:30AM +0200, Albin Tonnerre wrote: Please, no. This was intentionnaly reverted because it causes a build failure when using tarballs created by 'make distcheck', as the debian dir is not included in them (on purpose) On Tue, Jun 10, 2008 at 03:58:05AM -0400, Enlightenment CVS wrote : Enlightenment CVS committal Author : horms Project : e17 Module : libs/eet Dir : e17/libs/eet Modified Files: configure.in Log Message: Have configure create debian/changelog Not doing so seems to be an omission. === RCS file: /cvs/e/e17/libs/eet/configure.in,v retrieving revision 1.99 retrieving revision 1.100 diff -u -3 -r1.99 -r1.100 --- configure.in19 May 2008 16:47:37 - 1.99 +++ configure.in10 Jun 2008 07:58:01 - 1.100 @@ -204,6 +204,7 @@ AC_OUTPUT([ Makefile +debian/changelog eet.pc eet.c src/Makefile - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-cvs mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-cvs -- Albin Tonnerre - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Horms - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/eet horms
On Tue, Jun 10, 2008 at 01:35:22PM -0700, Michael Jennings wrote: On Tuesday, 10 June 2008, at 11:21:30 (+0200), Albin Tonnerre wrote: Please, no. This was intentionnaly reverted because it causes a build failure when using tarballs created by 'make distcheck', as the debian dir is not included in them (on purpose) I still think this is a huge mistake. It's a very simple matter for someone who doesn't want to use it to rm -rf a debian/ hierarchy that is already there. It's a hell of a lot harder for someone who *does* want to use it to reproduce it out of thin air. First, up sorry for the bother. I didn't realise that there was a new way to handle the Debian packaging wafting through the archive. Secondly, perhaps it would be better to improve the packaging, incoporating those changes being made by people maintaining pacakages for Debian, rather than delete it all together. Its seems to me that being able to check out code from cvs and build a debian package would be useful to some people. But perhaps I am the only person in that category :-) -- Horms - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH 8/8] Remove autogenerated file
On Fri, Mar 28, 2008 at 01:02:42AM +0100, Stefan Schmidt wrote: Hello. On Fri, 2008-03-14 at 01:06, Stefan Schmidt wrote: Remove autogenerated file. --- enm.pc | 11 --- 1 files changed, 0 insertions(+), 11 deletions(-) delete mode 100644 enm.pc Seems something was oing wrong on the way from patch to cvs to commit here. The file is still there. Just remove the autogenerated enm.pc file. I think that you need to explicitly use cvs remove in order to remove a file from the repository. If you just patch it out of existence then the effect is only that the file is removed locally. -- Horms - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
