Re: [E-devel] ABI break in eina ?
On Mon, Nov 14, 2011 at 1:22 AM, Carsten Haitzler ras...@rasterman.com wrote: On Sun, 13 Nov 2011 19:25:48 +0100 (CET) Vincent Torri vto...@univ-evry.fr said: comparison of symbols of eina 1.0.0 and 1.0.99 shows no exported symbols removed. only added. Yup. If memory serves, the function I had an issue with was eina_array_clean, which was moved from a symbol to header-exported inline function a while back. I don't remember exactly when this happened, but I think it was between 1.0.0 beta and the actual 1.0.0 (though it still technically is an ABI break, which is why I still export that symbol in the packages. heh.) Cheers, -- Albin Tonnerre -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore tests fail with beta3 tarballs
On Sat, 18 Dec 2010 17:14 +0100, Thomas Sachau wrote : Attached is a build log with the failures. Are you by any chance building on a headless machine, or in a tty ? If so, that failure is expected - the test fails whenever ecore can't reach the X server. I ended up disabling this test completely for the Debian packages. Cheers, -- Albin Tonnerre -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore tests fail with beta3 tarballs
On Sun, 19 Dec 2010 09:11 +0100, Vincent Torri wrote : tests are for developpers, not packagers That is terribly wrong. Packagers care about testsuites for one simple reason: as thoroughly as developers may be testing the code, that will never guarantee proper behaviour on the system on which the code is built. When creating packages for Debian, I /do/ care about the testsuites because the testsuite not failing is the only reliable thing telling me the lib is not utterly broken on the system it is being built on. I understand users not listening or unwilling to fix the suite to fit their needs is a pain, but let's not make it an even greater pain for people who just want to use it and manage to. Things have improved a lot as far as packaging is concerned in the last months, and this is clearly a step backwards. Please reconsider your decision. Cheers, -- Albin Tonnerre signature.asc Description: Digital signature -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore tests fail with beta3 tarballs
On Sun, 19 Dec 2010 22:14 +0900, Carsten Haitzler wrote : On Sun, 19 Dec 2010 10:28:20 +0100 Albin Tonnerre lu...@debian.org said: On Sun, 19 Dec 2010 09:11 +0100, Vincent Torri wrote : tests are for developpers, not packagers That is terribly wrong. Packagers care about testsuites for one simple reason: as thoroughly as developers may be testing the code, that will never guarantee proper behaviour on the system on which the code is built. When creating packages for Debian, I /do/ care about the testsuites because the testsuite not failing is the only reliable thing telling me the lib is not utterly broken on the system it is being built on. I understand users not listening or unwilling to fix the suite to fit their needs is a pain, but let's not make it an even greater pain for people who just want to use it and manage to. Things have improved a lot as far as packaging is concerned in the last months, and this is clearly a step backwards. tests are for developers so when they modify code they can check they didn't break anything. packagers can't do much with a test suite. At the very least, they can notice the testsuite is failing and investigate possible issues (and report them when/if approriate). does the linux kernel have a test suite that is run when people build packages? does xorg have one? i can continue with the list. they don't. Glibc does have one. GCC has one. And they do find bugs - especially tricky, architecture-specific ones. any test suites are part of the development cycle not the packaging cycle, but as they are in the sr4c tree, some gentoo devs seem to think that they should work as part of their ebuild (which is packaging). this is not the case. Are you purposedly ignoring my point here? I just explained why those suites are useful in the process of building packages. And not only to Gentoo devs, since I've been using them pretty much since they've been around. Besides, moving them away from src/ is basically making them harder for just about everyone, not just packagers. As bored as you might be by some people's behaviour, this is wrong. I think you did get your point across fairly clearly, but let's be realistic: you're not doing anyone - not even yourself - a favour by moving the tests away. Cheers, -- Albin Tonnerre signature.asc Description: Digital signature -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore tests fail with beta3 tarballs
On Sun, 19 Dec 2010 19:49 +0100, Vincent Torri wrote : On Sun, 19 Dec 2010, Albin Tonnerre wrote: On Sun, 19 Dec 2010 09:11 +0100, Vincent Torri wrote : tests are for developpers, not packagers That is terribly wrong. Packagers care about testsuites for one simple reason: as thoroughly as developers may be testing the code, that will never guarantee proper behaviour on the system on which the code is built. When creating packages for Debian, I /do/ care about the testsuites because the testsuite not failing is the only reliable thing telling me the lib is not utterly broken on the system it is being built on. I understand users not listening or unwilling to fix the suite to fit their needs is a pain, but let's not make it an even greater pain for people who just want to use it and manage to. Things have improved a lot as far as packaging is concerned in the last months, and this is clearly a step backwards. Please reconsider your decision. are you packaging the test suite ? I'm not sure what you mean exactly, but anyway: the testsuite is run when the package is built for at least eina and ecore. Cheers, -- Albin Tonnerre -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] ecore tests fail with beta3 tarballs
On Sun, 19 Dec 2010 20:02 +0100, Vincent Torri wrote : I understand users not listening or unwilling to fix the suite to fit their needs is a pain, but let's not make it an even greater pain for people who just want to use it and manage to. Things have improved a lot as far as packaging is concerned in the last months, and this is clearly a step backwards. keeping the unit tests inside the source code is a step backward ? Because that's what I want. Putting the unitt tests outside makes impossible (at least, i don't see anyway of doing that) coverage support. And that is for me a big step backward. I might have been misleading. I completely agree that tests should remain within the source tree - that's why I wrote that email in the first place :) Cheers, -- Albin Tonnerre -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e17 xdg menus
On Tue, Mar 22, 2011 at 9:13 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Hi all, Recently I had to do a new install and that's the time when you realize shortcomings exist :-) For instance I use Gentoo and we don't ship gnome-menus or kde-similar by default, so the result is an empty applications menu. Google reminded me of http://wiki.enlightenment.org/index.php/E17_and_Efreet with hints on how to hack around it. Not good if we're willing to release. Given that pulling in gnome-menus will bring in lots of unneeded stuff just for a handful of .directory or .menu, why not create our own and install it with E17 or Efreet? We can get either Gnome or KDE files and derive our own, that is always installed and we default to it. Comments, suggestions? That's what I've been doing in Debian for ages, and I completely agree with it. And please, *please* don't ship it with Efreet. It has nothing do there and rather belongs with E itself. Cheers, -- Albin Tonnerre -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] about removing trailing whitespaces
On Sun, 19 Jun 2011 12:38 +0200, Vincent Torri wrote : Hey another idea about trailing whitespaces : what about adding a rule in the toplevel Makefile.am, named for example remove-ws, that call find with a sed expression. I'll add it to Evil and test it a bit, and if nobody complains, i'll add it to the EFL + e. While it is nice to get rid of trailing whitespaces, I think that actively removing them periodically does more harm than good. In particular, it adds a lot of noise in the history and makes it harder to compare different revisions. If we indeed want to get rid of them, I'd be much happier if the SVN server simply rejected commits containing them (the same holds true for formatting - it's much better to ask people to submit properly formatted patches rather than going on a reformatting spree every now and then) Cheers, -- Albin Tonnerre -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Nightly build log for E17 on 2007-10-25 07:05:58 -0700
On Thu, Oct 25, 2007 at 11:21:58PM +0800, Toma wrote : This is from the 'ecore' build log checking whether ecore_desktop module is to be built... checking for dlopen in -ldl... (cached) yes ... config.status: creating ecore-desktop.pc ... Optional Modules: Ecore_Desktop: no Since this doesnt get built, engage fails on the test system. Could it be a bug in the ecore makefile? Ecore_Desktop is deprecated, superseded by efreet, and thus is disabled by configure unless told otherwise. Anyway, there's no real point in building engage for now, as it's (as far I can tell) completely broken. Cheers Albin On 25/10/2007, Nightly build system [EMAIL PROTECTED] wrote: Build log for Enlightenment DR 0.17 on 2007-10-25 07:05:58 -0700 Build logs are available at http://download.enlightenment.org/tests/logs Packages that failed to build: engage http://download.enlightenment.org/tests/logs/engage.log epdf http://download.enlightenment.org/tests/logs/epdf.log evolve http://download.enlightenment.org/tests/logs/evolve.log Packages with no supported build system: esmart_rsvg, exorcist, python-efl, Packages skipped: camE, 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, cpu, deskshow, eclair, ecore, edb, e_dbus, edje_editor, edje, edje_viewer, edvi, eet, eflame, eflpp, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, emotion, emphasis, empower, emu, engrave, engycad, enhance, enity, enterminus, enthrall, entice, entrance_edit_gui, entrance, entropy, envision, epeg, ephoto, e_phys, epsilon, equate, esmart, estickies, etk_extra, etk, etk-perl, evas, evfs, ewl, examine, exhibit, exml, expedite, express, extrackt, feh, flame, forecasts, gevas2, iconbar, imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, mixer, moon, net, news, pesh, photo, rage, rain, screenshot, scrot, 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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Albin Tonnerre, aka Lutin - Search a little longer, travel a little further signature.asc Description: Digital signature - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Use of the 'Requires.private' field in pkg-config files
Hello, I'd like to suggest that we use the new (as of pkg-config 0.22) 'Requires.private' flag in the .pc files instead of the current 'Requires' flag. 'Requires.private' is a field that basically has the same role as 'Requires'. However, the dependencies listed in this field are not used when `pkg-config --libs foobar' is called (only when dynamic linking is done, ie no --static is specified). This prevents unneeded recursive linking of the dependencies, like this is currently the case (eg, everything linked against ecore-file with CURL support enabled is also linked against curl, which is a maintenance hell and a complete nonsense, and this is one example out of many). That means that in our case, Requires.private field can replace Requires virtually everywhere if the dependencies have no undefined symbols and if they don't specify anything else than -l/-L flags. As a quick example of what the benefit would be, I rebuilt the EFL, E, etk and ewl using Requires.private instead of Requires in their pkg-config files, and ran objdump -p $foo | grep NEEDED on every {module,shared library,binary} before and after the change. The results can be found at http://people.dunnewind.net/lutin/files/efl_links--.diff The obvious drawback, of course, is that it would break build on every install where pkg-config 0.22 is not available, which is quite unpleasant, given that it's only 8-month old. I'm sending this mail for the record, though :) Cheers, -- Albin Tonnerre, aka Lutin signature.asc Description: Digital signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/ecore horms
On Mon, Feb 18, 2008 at 02:36:09AM -0500, Enlightenment CVS wrote : Enlightenment CVS committal Author : horms Project : e17 Module : libs/ecore Dir : e17/libs/ecore/debian Modified Files: rules Log Message: ecore: build ecore desktop The debian packaging has a libecore0-desktop package, so build ecore desktop so there is something to go in it. IMHO the correct way to do that would be to remove the ecore-desktop package. Ecore-desktop is superseded by efreet, and the only thing that still uses it in CVS is engage, which is utterly broken Cheers === RCS file: /cvs/e/e17/libs/ecore/debian/rules,v retrieving revision 1.17 retrieving revision 1.18 diff -u -3 -r1.17 -r1.18 --- rules 18 Feb 2008 07:34:43 - 1.17 +++ rules 18 Feb 2008 07:36:08 - 1.18 @@ -3,7 +3,7 @@ include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/autotools.mk -DEB_CONFIGURE_EXTRA_FLAGS := --disable-ecore-evas-dfb --disable-ecore-dfb --enable-ecore-fb +DEB_CONFIGURE_EXTRA_FLAGS := --disable-ecore-evas-dfb --disable-ecore-dfb --enable-ecore-fb --enable-ecore-desktop debian/stamp-autotools-files: ./autogen.sh --prefix=/usr $(DEB_CONFIGURE_EXTRA_FLAGS) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-cvs mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-cvs -- Albin Tonnerre, aka Lutin signature.asc Description: Digital signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: libs/evas horms
On Mon, Feb 18, 2008 at 02:20:50AM -0500, Enlightenment CVS wrote : Enlightenment CVS committal Author : horms Project : e17 Module : libs/evas Dir : e17/libs/evas Modified Files: Makefile.am Log Message: evas: include autogen.sh in distribution tar ball autogen.sh is really ought to be included in the distribution. For starters its used in the debian build process. No, it's not used by the debian build process During the build only ./configure is called. unless you explicitly call it, autogen.sh is _never_ needed during the build process. Having it part of the dist tarball doesn't help in any way, its only goal is to generate autofoo-related files which are already part of the tarball. It really does not belong to it. Cheers === RCS file: /cvs/e/e17/libs/evas/Makefile.am,v retrieving revision 1.49 retrieving revision 1.50 diff -u -3 -r1.49 -r1.50 --- Makefile.am 25 Jan 2008 04:40:28 - 1.49 +++ Makefile.am 18 Feb 2008 07:20:50 - 1.50 @@ -30,7 +30,7 @@ bin_SCRIPTS = -EXTRA_DIST = AUTHORS COPYING COPYING-PLAIN evas.c.in gendoc \ +EXTRA_DIST = AUTHORS COPYING COPYING-PLAIN autogen.sh evas.c.in gendoc \ Doxyfile \ README.in README \ evas.pc.in \ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-cvs mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-cvs -- Albin Tonnerre, aka Lutin - Search a little longer, travel a little further signature.asc Description: Digital signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ 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
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.in 19 May 2008 16:47:37 - 1.99 +++ configure.in 10 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 signature.asc Description: Digital signature - 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 02:13:32PM -0700, Michael Jennings wrote : On Tuesday, 10 June 2008, at 18:00:37 (-0300), Gustavo Sverzut Barbieri wrote: I'm not a packager myself, but all the packagers that I know hate this, and seems that it's written somewhere in debian packager docs that debian/ folders should not be part of the project. That's fine for the Debian project, but we aren't them, and we should not be beholden to their rules. If people want to make .deb packages for themselves directly from CVS, they should be able to (IMHO). If people want to do this, they *are* able to: all they need is checking out the CVS, which contains the debian dirs. If they want to make debs from snapshots, they can get the source package from the debian archive, as all the libs available as snapshots and e17 are in there. It is very wrong (also IMHO) for the Debian developers to make it difficult on those people just to make it easier on themselves. Well, if those packages are in Debian, all you need to do is basically run 'apt-get source foobar to get the source and the debian directory, so it's not really difficult. Cheers, Albin Again, it's always easier to remove something that exists than to create something that doesn't. And I *am* a packager. :-) (Albeit not a Debian one...but horms is.) as for those willing to create own ad-hoc packages, isn't checkinstall enough? checkinstall is what people use who don't actually know how to package, which are not the people we need to be targetting anyway. :) Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ [EMAIL PROTECTED] Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) --- Even in my heart I see you're not being true to me. Deep within my soul I feel nothing's like it used to be. -- Backstreet Boys, Quit Playing Games (With My Heart) - 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 -- Albin Tonnerre signature.asc Description: Digital signature - 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] E17 dbus support
Hello, On Sat, Sep 27, 2008 at 9:49 AM, Andreas Volz [EMAIL PROTECTED] wrote: Hello, may I add the script enlightenment_start_dbus to the SVN and install it by make install? - #!/bin/sh dbus-launch --exit-with-session enlightenment_start - It would be easy to document that for dbus support you've to execute that start script. What woule be the use case for this ? Users not using login managers might want to put that in their ~/.xinitrc (or whatever startx uses) instead, wouldn't they ? For example, here is the command I launch: /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /usr/bin/enlightenment_start I think that although this should be documented, adding a script which launches a single command (which doesn't necessarily fits the users's needs) might not really be worth installing by default. Cheers, Albin - 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] Language module
On Tue, Apr 24, 2007 at 12:42:01AM +0200, Nikolas Arend wrote : Hi, The language module in current cvs compiles and installes fine for me, but doesn't show up in the module settings and hence cannot be enabled. This seems like a simple issue, could anyone point me in the right direction to solve this? Thanks a lot, Nick. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel I'm not 100% sure about that, but I guess the desktop file hasn't been updated to work with efreet Cheers, -- Albin Tonnerre, aka Lutin signature.asc Description: Digital signature - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Bug: configure.in in exhibit, extrackt and moon not using pkg-config
On Wed, Apr 18, 2007 at 07:25:13PM +0200, Gaute Hope wrote : Hello Exhibit,extrackt and moon are not using pkg-config, but *package*-config in configure scripts. As far as i can see this is outdated and does not work with current CVS. Ubuntu Feisty with easy_e17.sh: http://ubuntuforums.org/showthread.php?t=97199 - gaute - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel A patch for moon has been applied yesterday, you should checkout the sources and try again :). Please let me know if it's not fixed. Cheers -- Albin Tonnerre, aka Lutin signature.asc Description: Digital signature - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E CVS: proto devilhorns
On Sat, Apr 28, 2007 at 02:40:15PM +0200, Stéphane Bauland wrote : Enlightenment CVS wrote: Enlightenment CVS committal Author : devilhorns Project : e17 Module : proto Dir : e17/proto/extrackt Modified Files: configure.in Log Message: Pkg-config patch from Lutin for extrackt. Works. === RCS file: /cvs/e/e17/proto/extrackt/configure.in,v retrieving revision 1.5 retrieving revision 1.6 diff -u -3 -r1.5 -r1.6 --- configure.in11 Sep 2006 21:32:48 - 1.5 +++ configure.in28 Apr 2007 10:42:27 - 1.6 @@ -91,63 +91,51 @@ AC_FUNC_LSTAT AC_FUNC_CLOSEDIR_VOID -#check for ecore -AC_PATH_EFL( - ecore, - 0.9.9, +PKG_CHECK_MODULES(ECORE, [ecore = 0.9.9], [ AC_DEFINE(HAVE_ECORE, 1, have ECORE) ecore=ECORE - ecore_libs=`ecore-config --libs` - ecore_includes=`ecore-config --cflags` + ecore_libs=$ECORE_LIBS + ecore_includes=$ECORE_CFLAGS ], [ - AC_MSG_ERROR([No ECORE, can't build.]) + AC_MSG_ERROR([No EVAS, can't build.]) ] ) MISTAKE ! + AC_MSG_ERROR([No EVAS, can't build.]) you said evas here, but it's ecore !!! xD see you... -#check for evas -AC_PATH_EFL( - evas, - 0.9.9, +PKG_CHECK_MODULES(EET, [eet = 0.9.10], [ - AC_DEFINE(HAVE_EVAS, 1, have EVAS) - evas=EVAS - evas_libs=`evas-config --libs` - evas_includes=`evas-config --cflags` + AC_DEFINE(HAVE_EET, 1, have EET) + eet=EET + eet_libs=$EET_LIBS + eet_includes=$EET_CFLAGS ], [ - AC_MSG_ERROR([No EVAS, can't build.]) + AC_MSG_ERROR([No EET, can't build.]) ] ) -#check for eet -AC_PATH_EFL( - eet, - 0.9.10, +PKG_CHECK_MODULES(EVAS, [evas = 0.9.9], [ - AC_DEFINE(HAVE_EET, 1, have EET) - eet=EET - eet_libs=`eet-config --libs` - eet_includes=`eet-config --cflags` + AC_DEFINE(HAVE_EVAS, 1, have EVAS) + evas=EVAS + evas_libs=$EVAS_LIBS + evas_includes=$EVAS_CFLAGS ], [ - AC_MSG_ERROR([No EET, can't build.]) + AC_MSG_ERROR([No EVAS, can't build.]) ] ) -#check for etk -AC_PATH_EFL( - etk, - 0.1.0, +PKG_CHECK_MODULES(ETK, [etk = 0.1.0], [ AC_DEFINE(HAVE_ETK, 1, have ETK) etk=ETK AM_CONDITIONAL(HAVE_ETK, true) AM_CONDITIONAL(BUILD_FRONTEND_ETK, true) have_etk=yes - etk_libs=`etk-config --libs` - etk_includes=`etk-config --cflags` + etk_libs=$ETK_LIBS + etk_includes=$ETK_CFLAGS ], [ AC_DEFINE(HAVE_ETK, 0, no ETK) @@ -160,22 +148,19 @@ ] ) -#check for enhance -AC_PATH_EFL( - enhance, - 0.0.1, +PKG_CHECK_MODULES(ENHANCE, [enhance = 0.0.1], [ AC_DEFINE(HAVE_ENHANCE, 1, have ENHANCE) enhance=ENHANCE AM_CONDITIONAL(HAVE_ENHANCE, true) have_enhance=yes - enhance_libs=`enhance-config --libs` - ehnahce_includes=`enhance-config --cflags` - if test x${have_etk} = xyes; then + enhance_libs=$ENHANCE_LIBS + ehnahce_includes=$ENHANCE_CFLAGS + if test x${have_etk} = xyes; then AM_CONDITIONAL(BUILD_FRONTEND_ETK, true) else AM_CONDITIONAL(BUILD_FRONTEND_ETK, false) - fi + fi ], [ AC_DEFINE(HAVE_ENHANCE, 0, no ENHANCE) @@ -184,7 +169,7 @@ AC_MSG_WARN([No Enhance, can't build ETK plugin.]) have_enhance=no enhance_libs= - enhance_includes= + enhance_includes= ] ) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-cvs mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-cvs - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel Yeah, I just noticed that. bad /me. no cookie :) -- Albin Tonnerre, aka Lutin - Search a little longer, travel a little further signature.asc Description: Digital signature - This SF.net email is sponsored
Re: [E-devel] E17 themes, etc.
On Wed, Jun 06, 2007 at 01:27:38PM +0200, muzzle wrote : On 6/6/07, Glen Larsen [EMAIL PROTECTED] wrote: Allow me to gush for just a moment. Brian just posted the return of Milky's and Simply-White and I had forgotten how much I missed those themes. Hi, this is just a quick note to tell you why I missed milky and simply white so much. I have a laptop with one of those glossy transreflective screen that becomes a perfect mirror when displaying dark colors. This means that 90% of the enlightenment themes are useless to me (awesome, but useless). The only 3 options I have are clearlooks, milky and simply white. So thanks a lot to lutin (and Glen and Gulivert and Tokyo) for creating/updating these themes. Keep up the good work in maintaining them, they are probably the only options for some people out there with a glossy laptop screen :) Thanks again and bye, Emme PS I'm glad lutin removed the sliding window title on get/loose focus from milky, it sucked way too many resources. That has *never* been a feature. I don't even know how it could have happened and actually, wasn't aware of this behavior. However, glad it works well for you now :) -- Aspetto un'emozione sempre piu' indefinibile (CCCP Fedeli alla linea) - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Albin Tonnerre, aka Lutin - Search a little longer, travel a little further signature.asc Description: Digital signature - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] download.enlightenment.org - Feature request
+1. that would be life-saving for the debian packages as well. btw, thank you guys for putting that on, it's awesome Albin -- Albin Tonnerre, aka Lutin - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] improvements of configure
While we're talking about configure... :) I'm part of the team which packages E for debian, and there's something in configure we'd really like to see changed (and of course we can provide patches): What we think is that when you enable a feature with --enable-whatever, and if the requirements of that feature are not found, configure should fail rather than silently disable it. The rationale for that is that, in our humble opinions, when you package for a distro, you want the stuff you enable to be actually present - thus, fail if not found rather than disable and tell nothing. As per discussion with raster on irc, I'm sure that some people may not want this behavior, and thus thought we could possibly add a --whatever-name-we-could-call-it , which implements such behavior (and let the default as it is) Thoughts ? (hint: 'this is your distro's problem is not a valid answer) Regards, Albin Tonnerre On Sun, Sep 30, 2007 at 03:01:32PM -0700, Michael Jennings wrote : On Sunday, 30 September 2007, at 16:04:54 (+0200), Vincent Torri wrote: Since I try to port the efl on windows, I've run into some problems with autofoo (strange, isn't it ?). I've looked a bit at autoconf and libtool doc, and I think that configure.in scripts can be improved a bit. Here is what I propose. Feel free to tell me if my proposals are not correct. ... Ideas ? remarks ? Most of that sounds fine, but why not provide us with a sample configure.in with examples of all 5 changes made to it so we can get a more concrete idea of what you're wanting to do? Then if people have any specific objections, they're easier to note. 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 am the one and only; nobody I'd rather be. I am the one and only. You can't take that away from me. -- Chesney Hawkes - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Albin Tonnerre, aka Lutin - Search a little longer, travel a little further signature.asc Description: Digital signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Selective build of modules for evas/ecore
On Fri, Oct 05, 2007 at 11:28:28AM +0900, Carsten Haitzler wrote : On Sun, 2 Sep 2007 21:16:31 +0200 Albin Tonnerre [EMAIL PROTECTED] babbled: On Sat, Aug 25, 2007 at 12:43:28PM +0900, Carsten Haitzler wrote : On Tue, 14 Aug 2007 16:50:09 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] babbled: Hi, I want to package e17 for maemo the proper way (so far I'm creating .deb with tar + ar and a custom shell script), but I'd like to disable build of some subpackages, like every evas engine other than software-x11 and software-16-x11 (which is not built right now). Maybe we could have a way to select which packages to generate? PS: May I add software-16-x11 to the list of build modules? sure - though really the debian or rpm packaging info is intended as a SAMPLE for packagers to build off - to show them how best to package and then add all the little bits their distribution demands or needs. it's a starting point rather than an end point - IMHO. :) About that Now that there is a team dedicated to package enlightenment for debian, is there really a point maintaining the debian/ dir *in* E's CVS ? I mean, this is generally seen as a bad practice in debian to have debian/ dirs bad in debian - not bad for us. basically it is meant to be: 1. an easy way for upstream to package themselves if they want. I'm quite dubious about the fact they'd want to package what they're developping (during the devel process). Just too much overhead to rebuild the package everytime you change something 2. a template/example of how to package for packagers (how to plit things up, what files to include or not include in packages (eg module .la and .a files are pointless so don't keep them), other special things (some binaries e produces are suid-root and so the packages need to reflect that, if they don't things won't work like cpufreq, system reboot/shutdown etc.). you, as a packager are free to strip this out or follow it, but it is your distribution, but this is our source - and we are giving a helping hand to you guys in many ways this way as per above. While this might help, they don't necessary belong to the source folder. If the packagers want exemples, easy enough for them to checkout the trees from a dedicated branch on the cvs. I understand that you want to provide samples etc, but as there are already ubuntu and debian repos available, I'm not quite sure that it is used by any user at all (of course falko uses them for the debian repo, but still), and it's mostly why I believe that moving them out of the sources wouldn't hurt much provided with upstream sources. As long as users now where the can grab the debian tree, wouldn't it possible to maintain it outside cvs ? Cheers in my experience, packagers of e have generally done a poor job (no offense intended). they have modified things, broken things, and left things in an inconsistent state (eg modifying e16 defaults but never updating the runtime help docs for starters). there have been other numerous mis-packagings of libs like evas which is modular, but keeping modules in the same package instead of splitting them out as separate packages that should be depended on not by evas, but by apps if they require certain engines/loaders etc. I can't remember having ever distributed evas as a single package since I started maintaining the ubuntu packaging a year back. While I understand that you experienced issues with various packagers, please keep in mind that it's not because some of them don't things the way they should be that every single packager does. Either ways, a good communication upstream - packging will be better than forcing packagers into doing things, and making their job harder (yes, keeping debian/ in the sources make our job harder. surprising isn't it ?) Regards Albin Tonnerre -- Gustavo Sverzut Barbieri -- Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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] 裸好多 Tokyo, Japan (東京 日本) - This SF.net email is sponsored
[E-devel] [PATCH] configure.ac: check for dlopen/dlsym and use -ldl for Ecore_X/Xlib
ecore_x/xlib/ecore_x_vsync.c uses dlopen and dlsym, but configure.ac only checks for this for the XCB variant. This results in linker errors when using strict linker flags (-Wl,-z,defs) --- configure.ac | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configure.ac b/configure.ac index 2060040..413264a 100644 --- a/configure.ac +++ b/configure.ac @@ -2772,6 +2772,9 @@ if test x${want_x11_xlib} = xyes ; then AC_DEFINE([HAVE_ECORE_X_XLIB], [1], [Defined to 1 if Xlib is enabled.]) HAVE_ECORE_X_BACKEND=HAVE_ECORE_X_XLIB + + EFL_EVAL_PKGS([ECORE_X]) + EFL_CHECK_FUNCS([ECORE_X], [dlopen dlsym]) fi ## XCB -- 1.8.4.rc3 -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Move binaries reserved for E internal use out of /usr/bin
Hi there, I think it might be a good idea to stop putting all the binairies e17 creates into /usr/bin, as half of them are actually only for internal use, and have nothing to do in $PATH. The attached patch moves the following binaries to /usr/lib/enlightenment and updates the code accordingly: - enlightenment_fm - enlightenment_fm_op - enlightenment_init - enlightenment_sys - enlightenment_thumb Toughts ? Regards, -- Albin Tonnerre diff -Nur e/src/bin/e_fm.c e.new/src/bin/e_fm.c --- e/src/bin/e_fm.c 2008-12-10 17:15:12.0 +0100 +++ e.new/src/bin/e_fm.c 2008-12-15 13:45:22.0 +0100 @@ -1511,7 +1511,7 @@ char buf[4096]; if (_e_fm2_client_spawning) return; - snprintf(buf, sizeof(buf), %s/enlightenment_fm, e_prefix_bin_get()); + snprintf(buf, sizeof(buf), %s/enlightenment/enlightenment_fm, e_prefix_lib_get()); exe = ecore_exe_run(buf, NULL); _e_fm2_client_spawning = 1; } diff -Nur e/src/bin/e_fm_main.c e.new/src/bin/e_fm_main.c --- e/src/bin/e_fm_main.c 2008-11-30 23:08:27.0 +0100 +++ e.new/src/bin/e_fm_main.c 2008-12-15 13:45:22.0 +0100 @@ -2175,7 +2175,7 @@ length = 256 + strlen(e_prefix_bin_get()) + strlen(args); buffer = malloc(length); - length = snprintf(buffer, length, %s/enlightenment_fm_op %s %s, e_prefix_bin_get(), command, args); + length = snprintf(buffer, length, %s/enlightenment_fm_op %s %s, e_prefix_lib_get(), command, args); return buffer; } diff -Nur e/src/bin/e_init.c e.new/src/bin/e_init.c --- e/src/bin/e_init.c 2008-11-30 23:08:27.0 +0100 +++ e.new/src/bin/e_init.c 2008-12-15 13:45:22.0 +0100 @@ -77,8 +77,8 @@ if (version) ver = strdup(e_util_filename_escape(version)); else ver = strdup(XvX); - snprintf(buf, sizeof(buf), %s/enlightenment_init \'%s\' \'%i\' \'%i\' \'%s\' \'%s\', - e_prefix_bin_get(), + snprintf(buf, sizeof(buf), %s/enlightenment/enlightenment_init \'%s\' \'%i\' \'%i\' \'%s\' \'%s\', + e_prefix_lib_get(), theme, e_canvas_engine_decide(e_config-evas_engine_init), e_config-font_hinting, diff -Nur e/src/bin/e_sys.c e.new/src/bin/e_sys.c --- e/src/bin/e_sys.c 2008-11-30 23:08:27.0 +0100 +++ e.new/src/bin/e_sys.c 2008-12-15 13:45:22.0 +0100 @@ -168,13 +168,13 @@ char buf[4096]; e_init_status_set(_(Checking System Permissions)); - snprintf(buf, sizeof(buf), %s/enlightenment_sys -t halt, e_prefix_bin_get()); + snprintf(buf, sizeof(buf), %s/enlightenment/enlightenment_sys -t halt, e_prefix_lib_get()); _e_sys_halt_check_exe = ecore_exe_run(buf, NULL); - snprintf(buf, sizeof(buf), %s/enlightenment_sys -t reboot, e_prefix_bin_get()); + snprintf(buf, sizeof(buf), %s/enlightenment/enlightenment_sys -t reboot, e_prefix_lib_get()); _e_sys_reboot_check_exe = ecore_exe_run(buf, NULL); - snprintf(buf, sizeof(buf), %s/enlightenment_sys -t suspend, e_prefix_bin_get()); + snprintf(buf, sizeof(buf), %s/enlightenment/enlightenment_sys -t suspend, e_prefix_lib_get()); _e_sys_suspend_check_exe = ecore_exe_run(buf, NULL); - snprintf(buf, sizeof(buf), %s/enlightenment_sys -t hibernate, e_prefix_bin_get()); + snprintf(buf, sizeof(buf), %s/enlightenment/enlightenment_sys -t hibernate, e_prefix_lib_get()); _e_sys_hibernate_check_exe = ecore_exe_run(buf, NULL); return 0; } @@ -515,8 +515,8 @@ case E_SYS_HALT_NOW: /* shutdown -h now */ if (e_util_immortal_check()) return 0; - snprintf(buf, sizeof(buf), %s/enlightenment_sys halt, - e_prefix_bin_get()); + snprintf(buf, sizeof(buf), %s/enlightenment/enlightenment_sys halt, + e_prefix_lib_get()); if (_e_sys_exe) { _e_sys_current_action(); @@ -542,8 +542,8 @@ case E_SYS_REBOOT: /* shutdown -r now */ if (e_util_immortal_check()) return 0; - snprintf(buf, sizeof(buf), %s/enlightenment_sys reboot, - e_prefix_bin_get()); + snprintf(buf, sizeof(buf), %s/enlightenment/enlightenment_sys reboot, + e_prefix_lib_get()); if (_e_sys_exe) { _e_sys_current_action(); @@ -568,8 +568,8 @@ break; case E_SYS_SUSPEND: /* /etc/acpi/sleep.sh force */ - snprintf(buf, sizeof(buf), %s/enlightenment_sys suspend, - e_prefix_bin_get()); + snprintf(buf, sizeof(buf), %s/enlightenment/enlightenment_sys suspend, + e_prefix_lib_get()); if (_e_sys_exe) { _e_sys_current_action(); @@ -594,8 +594,8 @@ break; case E_SYS_HIBERNATE: /* /etc/acpi/hibernate.sh force */ - snprintf(buf, sizeof(buf), %s/enlightenment_sys hibernate, - e_prefix_bin_get()); + snprintf(buf, sizeof(buf), %s/enlightenment/enlightenment_sys hibernate, + e_prefix_lib_get()); if (_e_sys_exe) { _e_sys_current_action(); diff -Nur e/src/bin/e_thumb.c e.new/src/bin/e_thumb.c --- e/src/bin/e_thumb.c 2008-11-30 23:08:27.0 +0100 +++ e.new/src/bin/e_thumb.c 2008-12-15 13:45:22.0 +0100 @@ -134,7 +134,7 @@ { Ecore_Exe *exe; - snprintf(buf, sizeof(buf), %s/enlightenment_thumb --nice=%d
Re: [E-devel] Move binaries reserved for E internal use out of /usr/bin
Hello, On Thu, Jan 1, 2009 at 1:56 AM, The Rasterman Carsten Haitzler ras...@rasterman.com wrote: no problem with this - though some people who like to be really nitty might say we should have a libexec/enlightenment dir... but really - not worth quibbling over. libexec is neither present in all distributions nor part of the FHS anyway, looks like a bad candidate lib is ok - it's inside e's dir and whatever e puts inside of that is e's business. but i'd move these to a subdir ie: PREFIX/lib/enlightenment/bin/ or PREFIX/lib/enlightenment/utils/ or something as modules are in modules/ - preload hacks in preload/ etc. :) All right, updated patch attached :) Cheers, Albin diff -Nur e/src/bin/e_fm.c e.new/src/bin/e_fm.c --- e/src/bin/e_fm.c 2008-12-28 11:18:18.0 +0100 +++ e.new/src/bin/e_fm.c 2009-01-01 17:28:52.0 +0100 @@ -1511,7 +1511,7 @@ char buf[4096]; if (_e_fm2_client_spawning) return; - snprintf(buf, sizeof(buf), %s/enlightenment_fm, e_prefix_bin_get()); + snprintf(buf, sizeof(buf), %s/enlightenment/utils/enlightenment_fm, e_prefix_lib_get()); exe = ecore_exe_run(buf, NULL); _e_fm2_client_spawning = 1; } diff -Nur e/src/bin/e_fm_main.c e.new/src/bin/e_fm_main.c --- e/src/bin/e_fm_main.c 2008-12-28 11:18:18.0 +0100 +++ e.new/src/bin/e_fm_main.c 2009-01-01 17:28:52.0 +0100 @@ -2177,7 +2177,7 @@ length = 256 + strlen(e_prefix_bin_get()) + strlen(args); buffer = malloc(length); - length = snprintf(buffer, length, %s/enlightenment_fm_op %s %s, e_prefix_bin_get(), command, args); + length = snprintf(buffer, length, %s/enlightenment/utils/enlightenment_fm_op %s %s, e_prefix_lib_get(), command, args); return buffer; } diff -Nur e/src/bin/e_init.c e.new/src/bin/e_init.c --- e/src/bin/e_init.c 2008-12-01 00:27:29.0 +0100 +++ e.new/src/bin/e_init.c 2009-01-01 17:28:52.0 +0100 @@ -77,8 +77,8 @@ if (version) ver = strdup(e_util_filename_escape(version)); else ver = strdup(XvX); - snprintf(buf, sizeof(buf), %s/enlightenment_init \'%s\' \'%i\' \'%i\' \'%s\' \'%s\', - e_prefix_bin_get(), + snprintf(buf, sizeof(buf), %s/enlightenment/utils/enlightenment_init \'%s\' \'%i\' \'%i\' \'%s\' \'%s\', + e_prefix_lib_get(), theme, e_canvas_engine_decide(e_config-evas_engine_init), e_config-font_hinting, diff -Nur e/src/bin/e_sys.c e.new/src/bin/e_sys.c --- e/src/bin/e_sys.c 2008-12-01 00:27:29.0 +0100 +++ e.new/src/bin/e_sys.c 2009-01-01 17:28:52.0 +0100 @@ -168,13 +168,13 @@ char buf[4096]; e_init_status_set(_(Checking System Permissions)); - snprintf(buf, sizeof(buf), %s/enlightenment_sys -t halt, e_prefix_bin_get()); + snprintf(buf, sizeof(buf), %s/enlightenment/utils/enlightenment_sys -t halt, e_prefix_lib_get()); _e_sys_halt_check_exe = ecore_exe_run(buf, NULL); - snprintf(buf, sizeof(buf), %s/enlightenment_sys -t reboot, e_prefix_bin_get()); + snprintf(buf, sizeof(buf), %s/enlightenment/utils/enlightenment_sys -t reboot, e_prefix_lib_get()); _e_sys_reboot_check_exe = ecore_exe_run(buf, NULL); - snprintf(buf, sizeof(buf), %s/enlightenment_sys -t suspend, e_prefix_bin_get()); + snprintf(buf, sizeof(buf), %s/enlightenment/utils/enlightenment_sys -t suspend, e_prefix_lib_get()); _e_sys_suspend_check_exe = ecore_exe_run(buf, NULL); - snprintf(buf, sizeof(buf), %s/enlightenment_sys -t hibernate, e_prefix_bin_get()); + snprintf(buf, sizeof(buf), %s/enlightenment/utils/enlightenment_sys -t hibernate, e_prefix_lib_get()); _e_sys_hibernate_check_exe = ecore_exe_run(buf, NULL); return 0; } @@ -515,8 +515,8 @@ case E_SYS_HALT_NOW: /* shutdown -h now */ if (e_util_immortal_check()) return 0; - snprintf(buf, sizeof(buf), %s/enlightenment_sys halt, - e_prefix_bin_get()); + snprintf(buf, sizeof(buf), %s/enlightenment/utils/enlightenment_sys halt, + e_prefix_lib_get()); if (_e_sys_exe) { _e_sys_current_action(); @@ -542,8 +542,8 @@ case E_SYS_REBOOT: /* shutdown -r now */ if (e_util_immortal_check()) return 0; - snprintf(buf, sizeof(buf), %s/enlightenment_sys reboot, - e_prefix_bin_get()); + snprintf(buf, sizeof(buf), %s/enlightenment/utils/enlightenment_sys reboot, + e_prefix_lib_get()); if (_e_sys_exe) { _e_sys_current_action(); @@ -568,8 +568,8 @@ break; case E_SYS_SUSPEND: /* /etc/acpi/sleep.sh force */ - snprintf(buf, sizeof(buf), %s/enlightenment_sys suspend, - e_prefix_bin_get()); + snprintf(buf, sizeof(buf), %s/enlightenment/utils/enlightenment_sys suspend, + e_prefix_lib_get()); if (_e_sys_exe) { _e_sys_current_action(); @@ -594,8 +594,8 @@ break; case E_SYS_HIBERNATE: /* /etc/acpi/hibernate.sh force */ - snprintf(buf, sizeof(buf), %s/enlightenment_sys hibernate, - e_prefix_bin_get()); + snprintf(buf, sizeof(buf), %s/enlightenment/utils/enlightenment_sys hibernate, + e_prefix_lib_get()); if (_e_sys_exe)
Re: [E-devel] E SVN: raster trunk/e/src/bin
Oh, sorry, didn't think about that :/ On Fri, Jan 2, 2009 at 12:19 PM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: fix things that broke after utils moved to lib/e/subdir Author: raster Date: 2009-01-02 03:19:06 -0800 (Fri, 02 Jan 2009) New Revision: 38418 Modified: trunk/e/src/bin/Makefile.am trunk/e/src/bin/e_fm_main.c trunk/e/src/bin/e_prefix.c Modified: trunk/e/src/bin/Makefile.am === --- trunk/e/src/bin/Makefile.am 2009-01-02 10:57:02 UTC (rev 38417) +++ trunk/e/src/bin/Makefile.am 2009-01-02 11:19:06 UTC (rev 38418) @@ -345,8 +345,7 @@ enlightenment_fm_SOURCES = \ e_fm_main.c \ e_user.c \ -e_sha1.c \ -e_prefix.c +e_sha1.c Now you might need e_utils.c too, or you'll end up with a build failure when compiling with multiple make jobs Cheers, Albin -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] SUID bits for E17
On Mon, Dec 15, 2008 at 7:12 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: I told you that :-) then you just need to do the dbus messages and have an option in enlightenment's configure.ac --enable-hal-shutdown and --enable-hal-cpufreq I'd vote for that, just don't have the time to do it myself. I'll have time when my exams are finished, I think I'll work on that if nobody does it before :) Cheers, Albin -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] signedness issues in efreet_menu.c
Hello, efreet_menu.c compare variables which have type 'char' to -1 (members of the Efreet_Menu_Internal and Efreet_Menu_Layout structures). This causes issues on architectures where chars are unsigned, such as ARM (at least on the freerunner). In particular, the use of Layout in menu files results in malformed menus. The attached patch intends to fix this. Regards, Albin Index: src/lib/efreet_menu.c === --- src/lib/efreet_menu.c (revision 39603) +++ src/lib/efreet_menu.c (working copy) @@ -61,11 +61,11 @@ Eina_List *layout; /** This menus layout */ Eina_List *default_layout; /** Default layout */ -char show_empty;/** Whether to show empty menus */ -char in_line; /** Whether this meny can be inlined */ -char inline_limit; /** Number of elements which triggers inline */ -char inline_header; /** Whether we should use the header name when this menu is inlined */ -char inline_alias; /** Whether we should use the menu name when inlining */ +signed char show_empty;/** Whether to show empty menus */ +signed char in_line; /** Whether this meny can be inlined */ +signed char inline_limit; /** Number of elements which triggers inline */ +signed char inline_header; /** Whether we should use the header name when this menu is inlined */ +signed char inline_alias; /** Whether we should use the menu name when inlining */ unsigned char seen_allocated:1; /** have we set the only_unallocated */ unsigned char only_unallocated:1; /** Show only unallocated .desktops */ @@ -184,11 +184,11 @@ char *name; /** The name of the element */ /* The items below are for Menuname Layout elements */ -char show_empty;/** Whether to show empty menus */ -char in_line; /** Whether this meny can be inlined */ -char inline_limit; /** Number of elements which triggers inline */ -char inline_header; /** Whether we should use the header name when this menu is inlined */ -char inline_alias; /** Whether we should use the menu name when inlining */ +signed char show_empty;/** Whether to show empty menus */ +signed char in_line; /** Whether this meny can be inlined */ +signed char inline_limit; /** Number of elements which triggers inline */ +signed char inline_header; /** Whether we should use the header name when this menu is inlined */ +signed char inline_alias; /** Whether we should use the menu name when inlining */ }; /** -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] Efreet: use eina_list instead of ecore_dlist
Hi, The attached patches fix three things: 0001 converts the remaining uses of ecore_dlist to using eina_list 0002 replaces the use of Eina_Compare_Cb with the use of EINA_COMPARE_CB 0003 Allows the e17-specified menu to be chosen as a menu only if STRICT_SPEC is not defined, as it is obviously not conforming to the spec. I tested a bit on my system and everything seems to be working correctly, however I haven't tested it really thoroughly. Comments welcome. Regards, -- Albin Tonnerre diff --git a/src/lib/efreet_desktop.c b/src/lib/efreet_desktop.c index 9357add..2dfa357 100644 --- a/src/lib/efreet_desktop.c +++ b/src/lib/efreet_desktop.c @@ -1089,7 +1089,7 @@ efreet_desktop_environment_check(Efreet_Ini *ini) /** * @param desktop: the desktop entry - * @param files: an ecore list of file names to execute, as either absolute paths, + * @param files: an eina list of file names to execute, as either absolute paths, * relative paths, or uris * @param func: a callback to call for each prepared command line * @param data: user data passed to the callback @@ -1105,8 +1105,8 @@ efreet_desktop_command_get(Efreet_Desktop *desktop, Eina_List *files, /** * @param desktop: the desktop entry - * @param files an ecore list of local files, as absolute paths, local paths, or file:// uris (or NULL to get exec string with no files appended) - * @return Returns an ecore list of exec strings + * @param files an eina list of local files, as absolute paths, local paths, or file:// uris (or NULL to get exec string with no files appended) + * @return Returns an eina list of exec strings * @brief Get the command to use to execute a desktop entry * * The returned list and each of its elements must be freed. @@ -1153,7 +1153,7 @@ efreet_desktop_command_local_get(Efreet_Desktop *desktop, Eina_List *files) /** * @param desktop: the desktop entry - * @param files: an ecore list of file names to execute, as either absolute paths, + * @param files: an eina list of file names to execute, as either absolute paths, * relative paths, or uris * @param cb_command: a callback to call for each prepared command line * @param cb_progress: a callback to get progress for the downloads diff --git a/src/lib/efreet_menu.c b/src/lib/efreet_menu.c index 1a77a38..57c85fa 100644 --- a/src/lib/efreet_menu.c +++ b/src/lib/efreet_menu.c @@ -41,7 +41,7 @@ struct Efreet_Menu_Internal } name; /** The names for this menu */ Efreet_Desktop *directory; /** The directory */ -Ecore_DList *directories; /** All the directories set in the menu file */ +Eina_List *directories; /** All the directories set in the menu file */ Efreet_Menu_Move *current_move; /** The current move */ @@ -50,7 +50,7 @@ struct Efreet_Menu_Internal Eina_List *app_pool; /** application pool */ Eina_List *applications; /** applications in this menu */ -Ecore_DList *directory_dirs;/** .directory file directories */ +Eina_List *directory_dirs;/** .directory file directories */ Eina_Hash *directory_cache;/** .directory dirs */ Eina_List *moves; /** List of moves to be handled by the menu */ @@ -1001,10 +1001,10 @@ efreet_menu_internal_free(Efreet_Menu_Internal *internal) internal-applications = eina_list_free(internal-applications); -IF_FREE_DLIST(internal-directories); +IF_FREE_LIST(internal-directories, free); IF_FREE_LIST(internal-app_dirs, efreet_menu_app_dir_free); IF_FREE_LIST(internal-app_pool, efreet_menu_desktop_free); -IF_FREE_DLIST(internal-directory_dirs); +IF_FREE_LIST(internal-directory_dirs, free); IF_FREE_HASH(internal-directory_cache); IF_FREE_LIST(internal-moves, efreet_menu_move_free); @@ -1053,10 +1053,10 @@ static int efreet_menu_handle_menu(Efreet_Menu_Internal *internal, Efreet_Xml *xml) { Efreet_Xml *child; +Eina_List *l; int (*cb)(Efreet_Menu_Internal *parent, Efreet_Xml *xml); -ecore_list_last_goto(xml-children); -while ((child = ecore_dlist_previous(xml-children))) +EINA_LIST_REVERSE_FOREACH(xml-children, l, child) { cb = eina_hash_find(efreet_menu_handle_cbs, child-tag); if (cb) @@ -1206,13 +1206,13 @@ efreet_menu_handle_directory_dir(Efreet_Menu_Internal *parent, Efreet_Xml *xml) if (!path) return 0; /* we've already got this guy in our list we can skip it */ -if (ecore_list_find(parent-directory_dirs, ECORE_COMPARE_CB(strcmp), path)) +if (eina_list_search_unsorted(parent-directory_dirs, EINA_COMPARE_CB(strcmp), path)) { FREE(path); return 1; } -ecore_dlist_prepend(parent-directory_dirs, path); +parent-directory_dirs = eina_list_prepend(parent-directory_dirs, path); return 1; } @@ -1237,10 +1237,10 @@ efreet_menu_handle_default_directory_dirs(Efreet_Menu_Internal *parent, Efreet_X desktop
Re: [E-devel] [PATCH] Efreet: use eina_list instead of ecore_dlist
Hi, Please find attached an updated patch which sets to NULL the pointer to a list being merged into another list. Regards, -- Albin Tonnerre diff --git a/src/lib/efreet_desktop.c b/src/lib/efreet_desktop.c index 9357add..2dfa357 100644 --- a/src/lib/efreet_desktop.c +++ b/src/lib/efreet_desktop.c @@ -1089,7 +1089,7 @@ efreet_desktop_environment_check(Efreet_Ini *ini) /** * @param desktop: the desktop entry - * @param files: an ecore list of file names to execute, as either absolute paths, + * @param files: an eina list of file names to execute, as either absolute paths, * relative paths, or uris * @param func: a callback to call for each prepared command line * @param data: user data passed to the callback @@ -1105,8 +1105,8 @@ efreet_desktop_command_get(Efreet_Desktop *desktop, Eina_List *files, /** * @param desktop: the desktop entry - * @param files an ecore list of local files, as absolute paths, local paths, or file:// uris (or NULL to get exec string with no files appended) - * @return Returns an ecore list of exec strings + * @param files an eina list of local files, as absolute paths, local paths, or file:// uris (or NULL to get exec string with no files appended) + * @return Returns an eina list of exec strings * @brief Get the command to use to execute a desktop entry * * The returned list and each of its elements must be freed. @@ -1153,7 +1153,7 @@ efreet_desktop_command_local_get(Efreet_Desktop *desktop, Eina_List *files) /** * @param desktop: the desktop entry - * @param files: an ecore list of file names to execute, as either absolute paths, + * @param files: an eina list of file names to execute, as either absolute paths, * relative paths, or uris * @param cb_command: a callback to call for each prepared command line * @param cb_progress: a callback to get progress for the downloads diff --git a/src/lib/efreet_menu.c b/src/lib/efreet_menu.c index 1a77a38..e11336a 100644 --- a/src/lib/efreet_menu.c +++ b/src/lib/efreet_menu.c @@ -41,7 +41,7 @@ struct Efreet_Menu_Internal } name; /** The names for this menu */ Efreet_Desktop *directory; /** The directory */ -Ecore_DList *directories; /** All the directories set in the menu file */ +Eina_List *directories; /** All the directories set in the menu file */ Efreet_Menu_Move *current_move; /** The current move */ @@ -50,7 +50,7 @@ struct Efreet_Menu_Internal Eina_List *app_pool; /** application pool */ Eina_List *applications; /** applications in this menu */ -Ecore_DList *directory_dirs;/** .directory file directories */ +Eina_List *directory_dirs;/** .directory file directories */ Eina_Hash *directory_cache;/** .directory dirs */ Eina_List *moves; /** List of moves to be handled by the menu */ @@ -1001,10 +1001,10 @@ efreet_menu_internal_free(Efreet_Menu_Internal *internal) internal-applications = eina_list_free(internal-applications); -IF_FREE_DLIST(internal-directories); +IF_FREE_LIST(internal-directories, free); IF_FREE_LIST(internal-app_dirs, efreet_menu_app_dir_free); IF_FREE_LIST(internal-app_pool, efreet_menu_desktop_free); -IF_FREE_DLIST(internal-directory_dirs); +IF_FREE_LIST(internal-directory_dirs, free); IF_FREE_HASH(internal-directory_cache); IF_FREE_LIST(internal-moves, efreet_menu_move_free); @@ -1053,10 +1053,10 @@ static int efreet_menu_handle_menu(Efreet_Menu_Internal *internal, Efreet_Xml *xml) { Efreet_Xml *child; +Eina_List *l; int (*cb)(Efreet_Menu_Internal *parent, Efreet_Xml *xml); -ecore_list_last_goto(xml-children); -while ((child = ecore_dlist_previous(xml-children))) +EINA_LIST_REVERSE_FOREACH(xml-children, l, child) { cb = eina_hash_find(efreet_menu_handle_cbs, child-tag); if (cb) @@ -1206,13 +1206,13 @@ efreet_menu_handle_directory_dir(Efreet_Menu_Internal *parent, Efreet_Xml *xml) if (!path) return 0; /* we've already got this guy in our list we can skip it */ -if (ecore_list_find(parent-directory_dirs, ECORE_COMPARE_CB(strcmp), path)) +if (eina_list_search_unsorted(parent-directory_dirs, EINA_COMPARE_CB(strcmp), path)) { FREE(path); return 1; } -ecore_dlist_prepend(parent-directory_dirs, path); +parent-directory_dirs = eina_list_prepend(parent-directory_dirs, path); return 1; } @@ -1237,10 +1237,10 @@ efreet_menu_handle_default_directory_dirs(Efreet_Menu_Internal *parent, Efreet_X desktop-directories); EINA_LIST_FOREACH(dirs, l, dir) { -if (ecore_list_find(parent-directory_dirs, ECORE_COMPARE_CB(strcmp), dir)) +if (eina_list_search_unsorted(parent-directory_dirs, EINA_COMPARE_CB(strcmp), dir)) continue; -ecore_dlist_prepend(parent-directory_dirs, strdup(dir)); +parent
Re: [E-devel] Fwd: [Proposal] release schedule and version numbering
On Thu, Apr 16, 2009 at 7:38 AM, Vincent Torri vto...@univ-evry.fr wrote: On Wed, 15 Apr 2009, Albin Tonnerre wrote: Patch attached. As usual, comments are welcome in ecore, is it really necessary to have a release-info for each module ? I think it's better, unless you want to force a SONAME change upon all the 18 libs every time one of them changes. That would force a lot of unneeded recompiles for programs who rely on parts which haven't changed (for example, if you break the ecore_win32 API, you sure don't want all the libs to change SONAME) Regards, Albin -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fwd: [Proposal] release schedule and version numbering
On Thu, Apr 16, 2009 at 9:57 AM, Vincent Torri vto...@univ-evry.fr wrote: in that case, is it good to specify both -release and -version-info in _LDFLAGS ? I think it's mostly a matter of taste. Keeping both doesn't hurt much IMHO, and all you'll have to do when there's a real release is remove the '-release' part. Albin -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fwd: [Proposal] release schedule and version numbering
On Thu, Apr 16, 2009 at 6:25 PM, sda dmitry.serpok...@gmail.com wrote: hi, just FYI - general rules for rpm packaging: http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html brief summary of packaging conventions which confirms to the LSB could be reviewed below (distro-specific!): http://en.opensuse.org/Packaging the offer above is about to change NAME - ???!!!. if (when) we settle the exact E-svn-revision numbers to be packaged and available for all the info like RC, Alpha, Beta, Fix1 to RC etc shoulg go to the Changelog or Summary (as a last resort). I'm sorry, but I don't understand what your point is. Regards, Albin -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fwd: [Proposal] release schedule and version numbering
On Thu, Apr 16, 2009 at 7:00 PM, Albin Tonnerre albin.tonne...@gmail.com wrote: On Thu, Apr 16, 2009 at 6:25 PM, sda dmitry.serpok...@gmail.com wrote: hi, just FYI - general rules for rpm packaging: http://www.rpm.org/max-rpm/s1-rpm-inside-tags.html brief summary of packaging conventions which confirms to the LSB could be reviewed below (distro-specific!): http://en.opensuse.org/Packaging the offer above is about to change NAME - ???!!!. if (when) we settle the exact E-svn-revision numbers to be packaged and available for all the info like RC, Alpha, Beta, Fix1 to RC etc shoulg go to the Changelog or Summary (as a last resort). This patch is not about changing package names. It's about getting proper SONAME changes when devs break the API or the ABI. What happends to the package names is not releveant to this, as this is the maintainer's decision. Regards, Albin -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] modules to disable by default in monday release
On Sun, Apr 19, 2009 at 06:03:06PM -0300, Gustavo Sverzut Barbieri wrote : n.b. - i'd disable in config profile, not build... ? new users will lose them - old users keep what they have. ok, I'd rather disable their build, but just in profiles is fine. I agree with raster. Unless those modules are broken, there's no point preventing users from trying them out - disabled at runtime is better IMHO. Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] fixes to configure.ac
On Thu, Apr 23, 2009 at 04:36:18AM +0200, Vincent Torri wrote : On Thu, 23 Apr 2009, Carsten Haitzler (The Rasterman) wrote: On Wed, 22 Apr 2009 16:29:18 -0400 Rodrigo Belem rclbe...@gmail.com said: Hi all, I was getting some build fails, so I notice that the error was coming from configure.ac. The patch is attached, but I did not tested if the others libs need this fix too. hmm i changed it for consistency in the version strip - it worked for me but not you (odd). i've gone the other way and removed all the []'s instead. it''s at least consistent maybe you should search why it does not work, instead of committing this I agree with vincent here, it's been this way for long and nobody ever had issues with it. Would you mind providing an error log so that we can try to understand why you were getting this error ? Cheers, -- Albin Tonnerre signature.asc Description: Digital signature -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: quaker IN trunk/E-MODULES-EXTRA
On Sat, Apr 25, 2009 at 04:05:01AM -0700, Enlightenment SVN wrote : EDJE_FLAGS = -v \ -id $(top_srcdir) \ --fd $(top_srcdir)/fonts +-fd $(top_srcdir) -fd is used to add a directory to look in for fonts. Unless I'm missing something, you no longer need it and should drop this line instead of just stripping fonts. Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;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] [PATCH] Replace Ecore_List2 with Eina_List
On Sun, Apr 26, 2009 at 10:48:40AM +0200, Vincent Torri wrote : On Sun, 26 Apr 2009, Albin Tonnerre wrote: Hello, The attached patches completely replace Ecore_List2 with Ecore_List. you mean with Eina_List ? Indeed. Thanks :) -- Albin Tonnerre signature.asc Description: Digital signature -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;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] [PATCH] Replace Ecore_List2 with Eina_List
On Mon, Apr 27, 2009 at 09:18:39AM -0300, Gustavo Sverzut Barbieri wrote : Sachiel is right, List2 is the same as Inlist, lists where the data is the node, you avoid a bit of memory fragmentation. Eina_List can use the eina mempool, why Inlist can't, so I wouldn't say using Inlists reduce memory fragmentation. and also another pointer redirection (-data). That's the argument for using inlists in the kernel. I'm not sure how this applies to ecore. They're better suited for elements that are always in a list (ie: Evas_Object always in evas), but you can still have them in other Eina_List (not inlist!) if you wish. The downside, at least at the moment, is that you don't have fast count operation, it need to walk the whole list in order to figure out how many elements exists. But you can append fast (O(1)) since it will keep a pointer to last element. Eina_List too. Anyway, TBH I only did it this way because cedric advised me to do so. I'll change it to Eina_Inlists if you think that really would have a benefit, which I doubt. Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;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
[E-devel] Accessing the structure containing an Eina_Inlist
Hello, While playing with Eina_Inlist, I noticed that given a pointer to an Eina_Inlist, one can't easily get a pointer to the structure containing it. The only option now is to put the Eina_Inlist first in the structure, and then cast this structure to an Eina_Inlist, which is far from optimal. I'd therefore like to propose that we add in eina_inlist.h a macro along the lines of #define FIND_A_SENSBILE_NAME_FOR_THIS(ptr, type) ((type *) ((Eina_Inlist *) ptr - offsetof(type, __in_list))) Then, we could get a pointer to the containing structure, no matter where the Eina_Inlist is (note that I used __in_list as the member as we already have a macro '#define EINA_INLIST Eina_Inlist __in_list', but a member argument could be added just as well) Thoughts ? Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: morlenxus trunk/E-MODULES-EXTRA/diskio/src
On Thu, Apr 30, 2009 at 06:15:10AM -0700, Enlightenment SVN wrote : Log: replace ecore with eina Author: morlenxus Date: 2009-04-30 06:15:10 -0700 (Thu, 30 Apr 2009) New Revision: 40474 Modified: trunk/E-MODULES-EXTRA/diskio/src/e_mod_config.c Modified: trunk/E-MODULES-EXTRA/diskio/src/e_mod_config.c === --- trunk/E-MODULES-EXTRA/diskio/src/e_mod_config.c 2009-04-30 10:13:31 UTC (rev 40473) +++ trunk/E-MODULES-EXTRA/diskio/src/e_mod_config.c 2009-04-30 13:15:10 UTC (rev 40474) @@ -3,7 +3,7 @@ struct _E_Config_Dialog_Data { - Ecore_List *disks; + Eina_List *disks; int diskpos; }; @@ -78,6 +78,7 @@ _basic_create(E_Config_Dialog *cfd, Evas *evas, E_Config_Dialog_Data *cfdata) { Config_Item *ci; + Eina_List *l; Evas_Object *o = NULL, *of = NULL, *ob = NULL; E_Radio_Group *rg; char path[128], *disk; @@ -93,8 +94,9 @@ if (cfdata-disks) { - while ((disk = ecore_list_next(cfdata-disks))) + for (l = cfdata-disks; l; l = eina_list_next(l)) { + disk = eina_list_data_get(l); pos++; EINA_LIST_FOREACH(cfdata-disks, l, disk) { ... } might be easier/better to use there Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Accessing the structure containing an Eina_Inlist
On Fri, May 01, 2009 at 10:13:09AM +1000, Carsten Haitzler wrote : On Thu, 30 Apr 2009 18:02:45 -0300 Gustavo Sverzut Barbieri barbi...@profusion.mobi said: On Thu, Apr 30, 2009 at 10:11 AM, Albin Tonnerre albin.tonne...@gmail.com wrote: Hello, While playing with Eina_Inlist, I noticed that given a pointer to an Eina_Inlist, one can't easily get a pointer to the structure containing it. The only option now is to put the Eina_Inlist first in the structure, and then cast this structure to an Eina_Inlist, which is far from optimal. I'd therefore like to propose that we add in eina_inlist.h a macro along the lines of #define FIND_A_SENSBILE_NAME_FOR_THIS(ptr, type) ((type *) ((Eina_Inlist *) #ptr - offsetof(type, __in_list))) Then, we could get a pointer to the containing structure, no matter where the Eina_Inlist is (note that I used __in_list as the member as we already have a macro '#define EINA_INLIST Eina_Inlist __in_list', but a member argument could be added just as well) Thoughts ? As we discussed on IRC, I like this. It would help avoid casts and try to make code bit easier to get right. much uglier as now you need to drag an offset Well, if the Eina_Inlist is the first member in the struct the compiler will probably optimize the substraction, as the offset would be 0. If it's not the first member, you need it anyway. # around all the time, and now you still need to cast anyway (use a raw pointer offset and cast to ah Inlist pointer). you don't get rid of it. Same here. The point is not only to avoid casts. It allows people to place the inlist wherever they want within a structure, and have easy access to it. Providing it in eina just doesn't cost anything, and allows people to do it painlessly. -- Albin Tonnerre signature.asc Description: Digital signature -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Accessing the structure containing an Eina_Inlist
On Fri, May 01, 2009 at 01:18:38PM +0200, Vincent Torri wrote : On Fri, 1 May 2009, Gustavo Sverzut Barbieri wrote: On Thu, Apr 30, 2009 at 9:13 PM, Carsten Haitzler ras...@rasterman.com wrote: The only problem I see and I already talked to Albin about it is on weird compilers without offsetof() macros. offsetof seems to exist in the lib c of Microsoft And FWIW, ISO C (both 89 and 99) says it should be defined in stddef.h, so if it doesn't exist you probably have more serious problems than this. -- Albin Tonnerre signature.asc Description: Digital signature -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] e17 crashes when loading/unloading modules
Hello, On my two computers, unloading and loading modules via the GUI gives a segfault. Apparently, it's due to _e_configure_module_update_cb being called, as the backtrace shows: 0x7f32973f3af3 in select () from /lib/libc.so.6 (gdb) bt #0 0x7f32973f3af3 in select () from /lib/libc.so.6 #1 0x7f329447382e in ?? () from /usr/lib/libxcb.so.1 #2 0x7f329447559a in xcb_wait_for_event () from /usr/lib/libxcb.so.1 #3 0x7f3297ced4a8 in ?? () from /usr/lib/libX11.so.6 #4 0x7f3297ced85d in ?? () from /usr/lib/libX11.so.6 #5 0x7f3297cee131 in _XReadEvents () from /usr/lib/libX11.so.6 #6 0x7f3297cd4958 in XNextEvent () from /usr/lib/libX11.so.6 #7 0x0048516f in e_alert_show ( text=0x4e2d48 This is very bad. Enlightenment SEGV'd.\n\nThis is not meant to happen and is likely a sign of\na bug in Enlightenment or the libraries it relies\non. You can gdb attach to this process now to try\ndebug i...) at e_alert.c:129 #8 0x0046f017 in e_sigseg_act (x=value optimized out, info=value optimized out, data=value optimized out) at e_signals.c:69 #9 signal handler called #10 eina_list_append (list=0x1, data=0x20fba50) at eina_list.c:566 #11 0x004a0b56 in _queue_append (obj=0x1736e20, command=4, icon=0x0, label=0x0, header=0, func=0, data=0x0, val=0x0, relative=0, use_relative=0, item=-1) at e_widget_ilist.c:222 #12 0x004a0ced in e_widget_ilist_selected_set (obj=0x1, n=value optimized out) at e_widget_ilist.c:598 #13 0x7f328e7bd4d9 in _e_configure_module_update_cb (data=0x1a68610, type=value optimized out, event=value optimized out) at e_conf.c:519 #14 0x7f32981f87d6 in _ecore_event_call () at ecore_events.c:439 #15 0x7f32982014e5 in _ecore_main_loop_iterate_internal (once_only=-1740584304) at ecore_main.c:679 #16 0x7f32982016f7 in ecore_main_loop_begin () at ecore_main.c:97 #17 0x0042ea5a in main (argc=1, argv=0x1550294) at e_main.c:1062 Looking at the source, I found that e_widget_ilist_selected_get is called with eco-cat_list as an argument, in e_conf.c. However, cat_list has been a widget_toolbar since November, so there's likely a mistake here and this call should probably be replaced with e_widget_toolbar_item_select However, I'm not sure how to fix this, as I'm not sure whether a call to e_widget_toolbar_item_select is necessary (the correct category is still selected without the function being called, eg when commenting out the whole callback). Also, I'm not sure why the callback is called when loading modules, in the first place. I'd appreciate if anyone had pointers and could enlighten me on the matter. Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: jeffdameth IN trunk/e: . data/themes src/modules src/modules/everything
Log: initial checkin of 'everything' module with sources for apps, windows and settings Author: jeffdameth Date: 2009-05-06 07:20:45 -0700 (Wed, 06 May 2009) New Revision: 40526 Maybe it deserves an email announcing it/explaining what it's for ? Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Accessing the structure containing an Eina_Inlist
On Fri, May 01, 2009 at 08:43:01AM -0300, Gustavo Sverzut Barbieri wrote : On Fri, May 1, 2009 at 8:34 AM, Albin Tonnerre albin.tonne...@gmail.com wrote: On Fri, May 01, 2009 at 01:18:38PM +0200, Vincent Torri wrote : On Fri, 1 May 2009, Gustavo Sverzut Barbieri wrote: On Thu, Apr 30, 2009 at 9:13 PM, Carsten Haitzler ras...@rasterman.com wrote: The only problem I see and I already talked to Albin about it is on weird compilers without offsetof() macros. offsetof seems to exist in the lib c of Microsoft And FWIW, ISO C (both 89 and 99) says it should be defined in stddef.h, so if it doesn't exist you probably have more serious problems than this. excellent, so no problems! So, commit or not commmit ? :) Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] CVS dependency on etk
On Sat, May 09, 2009 at 02:27:28AM +0200, Peter Wehrfritz wrote : Rodrigo Belem schrieb: Hi all, I was building etk so I saw that etk depends on cvs. This dependency comes from autopoint that lives in autogen.sh. So do all the core EFL, too rodr...@sculptor:/tmp/etk$ ./autogen.sh Running autopoint... autopoint: *** cvs program not found autopoint: *** Stop. Is it right? Do we need this? I wouldn't say it's ``right'', as gettext should arguably be depending on cvs. You can see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506022#17 and the related discussion for further information. Yes, autopoint has cvs as dep. And yes we need autopoint. At least I don't know a better way to setup gettext support. And it isn't a hard limitation, on the long run -- once e17 is released -- only packagers and developers need it. Packagers shouldn't even need it. Ideally, packages should be created using release tarballs, which are produced by make dist, and as a consequence one wouldn't need cvs (nor autopoint, for that matter) as ./autogen.sh has already been run Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Accessing the structure containing an Eina_Inlist
On Thu, May 07, 2009 at 10:53:06AM -0300, Gustavo Sverzut Barbieri wrote : On Thu, May 7, 2009 at 5:31 AM, Albin Tonnerre albin.tonne...@gmail.com wrote: On Fri, May 01, 2009 at 08:43:01AM -0300, Gustavo Sverzut Barbieri wrote : On Fri, May 1, 2009 at 8:34 AM, Albin Tonnerre albin.tonne...@gmail.com wrote: On Fri, May 01, 2009 at 01:18:38PM +0200, Vincent Torri wrote : On Fri, 1 May 2009, Gustavo Sverzut Barbieri wrote: On Thu, Apr 30, 2009 at 9:13 PM, Carsten Haitzler ras...@rasterman.com wrote: The only problem I see and I already talked to Albin about it is on weird compilers without offsetof() macros. offsetof seems to exist in the lib c of Microsoft And FWIW, ISO C (both 89 and 99) says it should be defined in stddef.h, so if it doesn't exist you probably have more serious problems than this. excellent, so no problems! So, commit or not commmit ? :) commit. Patch attached. Regard, -- Albin Tonnerre Index: eina/src/include/eina_inlist.h === --- eina/src/include/eina_inlist.h (revision 40723) +++ eina/src/include/eina_inlist.h (working copy) @@ -38,6 +38,7 @@ #define EINA_INLIST Eina_Inlist __in_list #define EINA_INLIST_GET(Inlist) (((Inlist)-__in_list)) +#define EINA_INLIST_CONTAINER_GET(ptr, type) ((type *) ((Eina_Inlist *) ptr - offsetof(type, __in_list))) EAPI Eina_Inlist * eina_inlist_append(Eina_Inlist *in_list, Eina_Inlist *in_item) EINA_ARG_NONNULL(2) EINA_WARN_UNUSED_RESULT; EAPI Eina_Inlist * eina_inlist_prepend(Eina_Inlist *in_list, Eina_Inlist *in_item) EINA_ARG_NONNULL(2) EINA_WARN_UNUSED_RESULT; signature.asc Description: Digital signature -- 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] build error of eina when configuring with --disable-magic-debug
On Sat, Jun 06, 2009 at 02:05:11PM +0200, Vincent Torri wrote : Hey, there is an error when configuring eina with --disable-magic-debug. Indeed, in that case, eina_magic_string_init is defined to : do {} while(0) and putting that in a if() is not that good. The same goes for eina_magic_string_shutdown, BTW. I don't know the best way to fix that. Imho, we should implement the function, which returns 1 if --disable-magic-debug is passed to configure. If you think that there is a better thing to do, please let me know (or fix it directly in svn) I agree with you here, I think having a function which returns 1 for init and 0 for shutdown is the best way to go. Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Fix eina build error with --disable-magic-debug, unified patch for my yesterday patches
On Sat, Jun 06, 2009 at 12:12:49PM -0300, Andre Dieb wrote : This patch contains my other two previous patches: - [PATCH] Fix eina mempool leak, init error handling, remove consumed TODO msg - [PATCH] Add checks to eina_module_new Also fixes the build error with --disable-magic-debug. I still think that when ecore_magic is disabled, it would be better to use functions rather than preprocessor macros for things like eina_magic_string_init(). Indeed, that would avoid exporting different symbols depending on whether eina has magic-debug enabled or not. If you use macros, an application using magic debug compiled against eina without magic-debug will have to be recompiled to benefit from it if it gets enabled in eina at a later point. If you use functions, this is no longer an issue. Thoughts ? Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Fix eina build error with --disable-magic-debug, unified patch for my yesterday patches
On Sat, Jun 06, 2009 at 07:20:39PM +0200, Cedric BAIL wrote : On Sat, Jun 6, 2009 at 5:48 PM, Albin Tonnerrealbin.tonne...@gmail.com wrote: On Sat, Jun 06, 2009 at 12:12:49PM -0300, Andre Dieb wrote : This patch contains my other two previous patches: - [PATCH] Fix eina mempool leak, init error handling, remove consumed TODO msg - [PATCH] Add checks to eina_module_new Also fixes the build error with --disable-magic-debug. I still think that when ecore_magic is disabled, it would be better to use functions rather than preprocessor macros for things like eina_magic_string_init(). Indeed, that would avoid exporting different symbols depending on whether eina has magic-debug enabled or not. If you use macros, an application using magic debug compiled against eina without magic-debug will have to be recompiled to benefit from it if it gets enabled in eina at a later point. If you use functions, this is no longer an issue. Thoughts ? I strongly disagree, when you disable magic debug in eina, you want to avoid it's cost at all. This include the call of the function call. And from my test, it does have a big impact to just enter an empty function. When we are speaking about performance, I think we can accept the little tradeoff of needing to recompile application using eina for maximum performance. If you're an application developer and use eina_magic, you're ready to pay that cost and more likely to rant about eina_magic being disabled than about any performance loss, as you explicitely asked for it. If you're talking about eina, nothing prevents us to do some trickery so that functions calls are avoided internally, while still exporting the symbols. Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] Fix eina build error with --disable-magic-debug, unified patch for my yesterday patches
On Sat, Jun 06, 2009 at 08:12:23PM +0200, Cedric BAIL wrote : On Sat, Jun 6, 2009 at 7:43 PM, Albin Tonnerrealbin.tonne...@gmail.com wrote: On Sat, Jun 06, 2009 at 07:20:39PM +0200, Cedric BAIL wrote : On Sat, Jun 6, 2009 at 5:48 PM, Albin Tonnerrealbin.tonne...@gmail.com wrote: On Sat, Jun 06, 2009 at 12:12:49PM -0300, Andre Dieb wrote : This patch contains my other two previous patches: - [PATCH] Fix eina mempool leak, init error handling, remove consumed TODO msg - [PATCH] Add checks to eina_module_new Also fixes the build error with --disable-magic-debug. I still think that when ecore_magic is disabled, it would be better to use functions rather than preprocessor macros for things like eina_magic_string_init(). Indeed, that would avoid exporting different symbols depending on whether eina has magic-debug enabled or not. If you use macros, an application using magic debug compiled against eina without magic-debug will have to be recompiled to benefit from it if it gets enabled in eina at a later point. If you use functions, this is no longer an issue. Thoughts ? I strongly disagree, when you disable magic debug in eina, you want to avoid it's cost at all. This include the call of the function call. And from my test, it does have a big impact to just enter an empty function. When we are speaking about performance, I think we can accept the little tradeoff of needing to recompile application using eina for maximum performance. If you're an application developer and use eina_magic, you're ready to pay that cost and more likely to rant about eina_magic being disabled than about any performance loss, as you explicitely asked for it. Well, in my opinion, when doing development I use magic debug for easing the stabilisation of my code, but in production I don't want to pay a price at all. That would mean that you rely on a production build of eina without magic debug, and one with magic debug, and that you would recompile your app against the production build of eina when you don't want magic debug. I don't think that's a valid use case, as you as a developper should put guards around uses of eina_magic *in your application* so that in doesn't get used when you don't want to. Relying on eina providing macros or functions just looks like a bad idea to me. Regards, - Albin Tonnerre signature.asc Description: Digital signature -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [Fwd: embryo: FTBFS on hurd-i386]
Hi there, Here's a bug report that got submitted on the Debian BTS, with a patch allowing embryo to compile on debian/hurd (and more generally on systems were PATH_MAX is udefined). Regards, -- Albin Tonnerre ---BeginMessage--- Package: embryo Severity: important Tags: patch Justification: fails to build from source embryo defines the _MAX_PATH constant, since PATH_MAX is optional according to POSIX. But there's still one occurrence of PATH_MAX in the source, which prevents embryo from building on GNU/Hurd. I have attached a patch that fixes this minor problem. Manuel Menal diff -urp embryo-0.9.9.050+svn20090204/src/bin/embryo_cc_sc1.c ../embryo-0.9.9.050+svn20090204/src/bin/embryo_cc_sc1.c --- embryo-0.9.9.050+svn20090204/src/bin/embryo_cc_sc1.c2009-02-04 21:16:57.0 +0100 +++ ../embryo-0.9.9.050+svn20090204/src/bin/embryo_cc_sc1.c 2009-06-23 12:03:37.0 +0200 @@ -603,7 +603,7 @@ static void parseoptions(int argc, char **argv, char *iname, char *oname, char *pname __UNUSED__, char *rname __UNUSED__) { - char str[PATH_MAX]; + char str[_MAX_PATH]; int i, stack_size; size_t len; -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: hurd-i386 (i686-AT386) Kernel: GNU-Mach 1.3.99/Hurd-0.3 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash ___ Pkg-e-devel mailing list pkg-e-de...@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-e-devel ---End Message--- signature.asc Description: Digital signature -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [eet] Update libeet1.symbols file
On Sun, Aug 16, 2009 at 09:10:38PM +0700, Mikhail Gusarov wrote : Those symbols appeared earlier than in 1.2.2, but debian/libeet1.symbols was not updated, so there is no point to look at the actual minimal versions of symbols. Actually, it did get updated, SVN just didn't follow: see http://git.debian.org/?p=pkg-e/libs/eet.git;a=history;f=debian/libeet1.symbols;h=deb0e65f90dbb9aa49afb20feb2e0626970aa138;hb=master Cheers, -- Albin Tonnerre signature.asc Description: Digital signature -- 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] Evas bugger
On Mon, Aug 24, 2009 at 06:07:20PM +0700, Mikhail Gusarov wrote : Twas brillig at 06:55:12 24.08.2009 UTC-04 when cpmicha...@comcast.net did gyre and gimble: CM regardless of platform the returns are as expected. NULL is declared as 0 in C standard. Consistency wins, I agree, but portability is not hurt by using 0 instead of NULL. IIRC a conformant C implementation could define NULL to (void *) 0 Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- 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: turning pkg-config's Requires: fiels into Requires.private
On Fri, Sep 04, 2009 at 03:36:28AM +0700, Mikhail Gusarov wrote : Twas brillig at 22:30:44 03.09.2009 UTC+02 when vto...@univ-evry.fr did gyre and gimble: VT Looks good to me. I've looked at others .og files (in fontconfig VT for example), and I have seen a Libs.private. SHould it be used ? Yes, of course! The rule of thumb is when something is not needed to link with a shared library, it goes to {Requires,Libs}.private As far as the EFL are concerned Requires.private can replace Requires virtually everywhere, however this is not true /at all/ for Libs. In fact, most of what's in Libs currently shouldn't move to Libs.private, because they actually are justified. Cheers, -- Albin Tonnerre signature.asc Description: Digital signature -- 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: turning pkg-config's Requires: fiels into Requires.private
On Thu, Sep 03, 2009 at 11:02:34PM +0200, Vincent Torri wrote : On Thu, 3 Sep 2009, Albin Tonnerre wrote: On Fri, Sep 04, 2009 at 03:36:28AM +0700, Mikhail Gusarov wrote : Twas brillig at 22:30:44 03.09.2009 UTC+02 when vto...@univ-evry.fr did gyre and gimble: VT Looks good to me. I've looked at others .og files (in fontconfig VT for example), and I have seen a Libs.private. SHould it be used ? Yes, of course! The rule of thumb is when something is not needed to link with a shared library, it goes to {Requires,Libs}.private As far as the EFL are concerned Requires.private can replace Requires virtually everywhere, however this is not true /at all/ for Libs. In fact, most of what's in Libs currently shouldn't move to Libs.private, because they actually are justified. are you sure ? http://people.freedesktop.org/~dbn/pkg-config-guide.html shouln't -liconv be in Libs.private ? [23:35 ~/e17/svn/trunk:svn|r42212]% find -name \*.pc.in | xargs grep iconv zsh: done find -name \*.pc.in | zsh: exit 123 xargs grep iconv I've never stated that Libs and Libs.private were all correctly set. I said that *most* of what is currently in Libs shouldn't move to Libs.private, and that's correct. Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- 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, 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? Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- 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] resolve eet build failure
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 ? Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- 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] [Fwd: embryo: FTBFS on hurd-i386]
On Sun, 05 Jul 2009 12:45 -0300, Gustavo Sverzut Barbieri wrote : On Sun, Jul 5, 2009 at 9:22 AM, Albin Tonnerrealbin.tonne...@gmail.com wrote: Hi there, Here's a bug report that got submitted on the Debian BTS, with a patch allowing embryo to compile on debian/hurd (and more generally on systems were PATH_MAX is udefined). I could apply this patch, but I fear it's nothing compared to the whole EFL where PATH_MAX is heavily used. I guess that a better option is to define PATH_MAX = 4096/1024/something-user-specified in config.h, which should be included in every source file anyway. With that new .m4, we could just copy it to all efl projects and call the macro from configure.ac and fix them in the same way. Would the following patch do the trick? --- /dev/null 2009-11-21 13:03:47.817351087 +0100 +++ m4/efl_path_max.m4 2009-11-21 16:43:28.0 +0100 @@ -0,0 +1,33 @@ +dnl Check for PATH_MAX in limits.h, and define a default value if not found +dnl This is a workaround for systems not providing PATH_MAX, like GNU/Hurd + +dnl EFL_CHECK_PATH_MAX([DEFAULT_VALUE_IF_NOT_FOUND]) +dnl +dnl If PATH_MAX is not defined in limits.h, defines it +dnl to DEFAULT_VALUE_IF_NOT_FOUND if it exists, or fallback +dnl to using 4096 + +AC_DEFUN([EFL_CHECK_PATH_MAX], +[ + +default_max=m4_default([$1], 4096) +AC_LANG_PUSH([C]) + +AC_MSG_CHECKING([for PATH_MAX in limits.h]) +AC_COMPILE_IFELSE( + [AC_LANG_PROGRAM([[#include limits.h]], +[[int i = PATH_MAX;]]) + ], + AC_MSG_RESULT([yes]), + [ + AC_DEFINE_UNQUOTED([PATH_MAX], +[${default_max}], +[default value since PATH_MAX is not defined]) + AC_MSG_RESULT([no: using ${default_max}]) + ] +) + +AC_LANG_POP([C]) + +]) +dnl end of efl_path_max.m4 Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- 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] [Fwd: embryo: FTBFS on hurd-i386]
On Sun, 22 Nov 2009 12:33 +1100, Carsten Haitzler wrote : On Sat, 21 Nov 2009 16:44:54 +0100 Albin Tonnerre albin.tonne...@gmail.com said: On Sun, 05 Jul 2009 12:45 -0300, Gustavo Sverzut Barbieri wrote : On Sun, Jul 5, 2009 at 9:22 AM, Albin Tonnerrealbin.tonne...@gmail.com wrote: Hi there, Here's a bug report that got submitted on the Debian BTS, with a patch allowing embryo to compile on debian/hurd (and more generally on systems were PATH_MAX is udefined). I could apply this patch, but I fear it's nothing compared to the whole EFL where PATH_MAX is heavily used. I guess that a better option is to define PATH_MAX = 4096/1024/something-user-specified in config.h, which should be included in every source file anyway. With that new .m4, we could just copy it to all efl projects and call the macro from configure.ac and fix them in the same way. Would the following patch do the trick? hmmm... platforms that dont have a PATH_MAX. ew. well it'd need to not just be added, but be used and everything made sure to include config.h if it doesnt explicitly or implicitly yet Sure, but at least that's a first step. Just wanted to make sure you were OK with the patch before spending more time on this. Regards, -- Albin Tonnerre -- 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] [Fwd: embryo: FTBFS on hurd-i386]
On Sun, 22 Nov 2009 12:33 +1100, Carsten Haitzler wrote : On Sat, 21 Nov 2009 16:44:54 +0100 Albin Tonnerre albin.tonne...@gmail.com said: On Sun, 05 Jul 2009 12:45 -0300, Gustavo Sverzut Barbieri wrote : On Sun, Jul 5, 2009 at 9:22 AM, Albin Tonnerrealbin.tonne...@gmail.com wrote: Hi there, Here's a bug report that got submitted on the Debian BTS, with a patch allowing embryo to compile on debian/hurd (and more generally on systems were PATH_MAX is udefined). I could apply this patch, but I fear it's nothing compared to the whole EFL where PATH_MAX is heavily used. I guess that a better option is to define PATH_MAX = 4096/1024/something-user-specified in config.h, which should be included in every source file anyway. With that new .m4, we could just copy it to all efl projects and call the macro from configure.ac and fix them in the same way. Would the following patch do the trick? hmmm... platforms that dont have a PATH_MAX. ew. well it'd need to not just be added, but be used and everything made sure to include config.h if it doesnt explicitly or implicitly yet Or, as initially suggested in the debian bugreports, we could just stop using PATH_MAX and use dynamic allocations. The bug submitter submitted patches for that. What do you prefer ? Regards, -- Albin Tonnerre -- 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] Using the release name in paths in e17
On Sat, 05 Dec 2009 15:58 +0200, Tom Hacohen wrote : Hey, ATM there's that weird module arch in the path of the modules: MODULE_ARCH=$(host_os)-$(host_cpu)-$(release) For instance, if I want to be able to write my own app with pages for the wizard module, I can't. I'll have to manually set the module arch if I want it to install to the proper place (because of the release version). I don't get what is it for anyway, I can hardly get the module_arch in general, but at least, if you use that, what's the release for? making sure people don't stuff modules after backwards compatibility is broken? In conclusion I see this as a bug in design that's blocking us from effectively installing 3rd party modules. As annoying as you may find it, that's not a blocking issue. You can get the release number using `pkg-config --variable=release enlightenment` Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: devilhorns IN trunk/efreet/src: bin lib
On Thu, 24 Dec 2009 12:16 +0100, Vincent Torri wrote : On Thu, 24 Dec 2009, Brett Nash wrote: Also, doing sizeof() is a compiler directive so does not incur any performance hits...plus it matches the rest of EFL. using a macro does not involved any performance hit too as PATH_MAX is directly replaced by its value before the compilation. Yes, but it's a damn big performance hit when someone changes one size, but not the other and the whole thing falls over in a steaming heap... ;-) if someone changes the size of the buffer without looking how the buffer is used, it should stop coding and try to be cabinetmaker of fisherman Of course. However, not using the buffer size directly avoids unnecessary code changes, no matter how carefully you check the code. So far, I've yet to see any reasonable argument as to why you're seemingly so hostile to this change. Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ubuntu packages
On Tue, 05 Jan 2010 08:39 +0800, Tom Haste wrote : Hey chums! As some of you might be aware, theres been a bit of back and forwards on Ubuntu launchpad bug on getting python-efl ( EFL) into the official ubuntu forums. I know its hardly any of our responsibility but I know some of the package folks from Debian would be interested in this. It also provides distribution of EFL in the biggest linux distro ever (Which would be quite nice). Lets leave out the fact that its still unreleased software, and see it as an opportunity to generate some usage, bugs, and more importantly, developers. Anyway, heres the Packaging Guidlines for ubuntu. https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages It says... Debian Import Freeze for lucid is on February 11, 2010. which gives us a month to see if we can get the debain experimental packages into Ubuntu. They're no longer in Debian experimental, but in unstable. If you want the packages to be in Ubuntu, the best way to achieve that is to ask for a sync report, so that the packages from Debian are imported into Ubuntu. AFAIK there should be no ubuntu-specific changes, so there's no reason not to sync directly. Please see https://wiki.ubuntu.com/SyncRequestProcess Id be happy to put in some effort to getting it in. Anyone else have experience in getting packages into Debian/Ubuntu? Sure. Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Emotion failing to configure on latest Ubuntu.
On Tue, 05 Jan 2010 13:02 +1000, David Seikel wrote : Apparently emotions checking of the version of gstreamer is getting confused with the version numbers used by the latest Ubuntu. checking for GSTREAMER... configure: error: Package requirements (gstreamer-0.10 = 0.10.2 gstreamer-plugins-base-0.10 = 0.10.1 evas = 0.9.9) were not met: No package 'gstreamer-plugins-base-0.10' found Version 0.10.25 of both required gstreamer packages is in fact installed. I'm not upto fixing this quickly, as I lack knowledge in how version numbers are compared. gstreamer-plugins-base-0.10 is part of libgstreamer-plugins-base0.10-dev, are you sure you installed it? Here on Ubuntu Karmic, it seems to work correctly once installed: [7:45 ~]% pkg-config --exists 'gstreamer-plugins-base-0.10 = 0.10.1'; echo $? 0 Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] merge ecore job and txt into ecore?
On Fri, 22 Jan 2010 11:32 +0100, Cedric BAIL wrote : Good idea to start discussing about ecore. On Fri, Jan 22, 2010 at 1:32 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Thu, Jan 21, 2010 at 10:25 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Why ecore_job and ecore_txt are split? They are so stupid that is should go into main ecore. Anyone with time to merge this and fix all apps that pkg-config ecore-job or ecore-txt to use simply ecore? If there's a general agreement that moving ecore_txt, ecore_job and ecore_input to ecore is a good thing, I'm willing to work on it. Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] merge ecore job and txt into ecore?
On Fri, 22 Jan 2010 23:19 +0100, Vincent Torri wrote : On Fri, 22 Jan 2010, Gustavo Sverzut Barbieri wrote: On 1/22/10, Albin Tonnerre albin.tonne...@gmail.com wrote: On Fri, 22 Jan 2010 11:32 +0100, Cedric BAIL wrote : Good idea to start discussing about ecore. On Fri, Jan 22, 2010 at 1:32 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Thu, Jan 21, 2010 at 10:25 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Why ecore_job and ecore_txt are split? They are so stupid that is should go into main ecore. Anyone with time to merge this and fix all apps that pkg-config ecore-job or ecore-txt to use simply ecore? If there's a general agreement that moving ecore_txt, ecore_job and ecore_input to ecore is a good thing, I'm willing to work on it. i believe nobody will disagree. if you do, also do for ecore_str.h move to eina. As cedric said. why not moving ecore_txt to eina, btw ? As far as I understand it, eina is about providing data types. IMHO neither ecore_str nor ecore_txt fit in that category. Cheers, -- Albin Tonnerre signature.asc Description: Digital signature -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] merge ecore job and txt into ecore?
On Sun, 24 Jan 2010 00:02 +0100, Vincent Torri wrote : to summarize: * ecore_txt moved in eina I think we'll just have to agree to disagree here :) * ecore_job merged in ecore I've made a patch doing this. * nothing done for ecore_file (raster wants it in ecore) Do you mean ecore_input here ? I would like ecore_input_evas being not merged into ecore_input. The reason is that if so, ecore_input depends on evas. As ecore_x and other graphic subsystems depends on ecore_input, that would mean that ecore_x would then depend on evas, which is not good. Merging ecopre_input_evas into ecore_input is not the question. I'm more curious about merging ecore_input in ecore. Since englebass split the evas-specific parts out, it means that ecore_input is basically a handful functions only relying on ecore. Hence, I don't see any clear rationale as to why we should keep it separate. Regards, -- Albin Tonnerre -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: quaker trunk/packaging/debian/extras/entrance
On Sun, 24 Jan 2010 09:17 -0800, Enlightenment SVN wrote : Log: Entrance - fix deb stuff DEB_MAKE_CLEAN_TARGET := distclean -DEB_CONFIGURE_EXTRA_FLAGS := --disable-rpath +DEB_CONFIGURE_EXTRA_FLAGS := --disable-rpath --with-xbin=/usr/bin clean:: [ ! -f Makefile ] || make distclean AFAIK, /usr/bin is pretty common path for the X binary these days. What about fixing configure.ac instead? Regards, -- Albin Tonnerre -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: quaker IN trunk/devs: . romanhornik
On Mon, 25 Jan 2010 15:22 -0600, Stephen Houston wrote : On Jan 25, 2010, at 3:15 PM, Albin Tonnerre albin.tonne...@gmail.com wrote: On Mon, 25 Jan 2010 15:07 -0600, Stephen Houston wrote : On Jan 25, 2010, at 2:57 PM, Vincent Torri vto...@univ-evry.fr wrote: On Mon, 25 Jan 2010, Stephen Houston wrote: I don't think this is a problem... If we are interested in widespread use of our software, then packages/packagers are an essential part of the process. it's not our job to package our libs and binaries... It's the job of the package managers of the different distros. They have their own repositories. Vincent Bit of a different situation when it's software in a versioning control tree that is constantly changing and hasn't been released in 10 years. Please, let's not turn this into yet another release-related troll. Several distributions have official packages for e17. Even though they don't provide all the applications that are in SVN, I think that's a pretty good step forward. Ummm? Chill out. No one is asking when or questioning whether the software should be released. Slow down and read what I said in context. Due to the fact of the release circumstances, it makes packaging a different situation. Completely relevant. I've been maintaining all the EFL-related package in Debian for the past 2 years. Believe me, I completely understand what it's like dealing with this situation. While I acknowledge that this used to be a PITA (things improved quite a bit recently), I'm pretty convinced that maintaing my packages in the SVN would have made my work even harder. Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster IN trunk/eina: . src/include src/lib src/modules/mp/buddy src/modules/mp/chained_pool src/modules/mp/ememoa_fixed src/modules/mp/ememoa_unknown src/modules/mp/fixed_bitmap
On Tue, 26 Jan 2010 07:54 -0800, Enlightenment SVN wrote : Log: eina - does modules like the rest of efl, so it's able to be installed with multiple versions at the same time. eventually will neeed to also include major number in release name too. /* dynamic backends */ - _modules = eina_module_list_get(NULL, PACKAGE_LIB_DIR /eina-VMAJ/mp/, 0, NULL, NULL); + _modules = eina_module_arch_list_get(NULL, PACKAGE_LIB_DIR /eina/modules/mp, MODULE_ARCH); - path = eina_module_environment_path_get(HOME, /.eina-VMAJ/mp/); - _modules = eina_module_list_get(_modules, path, 0, NULL, NULL); + path = eina_module_environment_path_get(HOME, /.eina/mp/modules/mp); + _modules = eina_module_arch_list_get(_modules, path, MODULE_ARCH); if (path) free(path); Err. The major number was alredy present and consistent with the naming scheme for the eina includes...You just reverted it. Regards, -- Albin Tonnerre -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Ecore_Job is gone (was: merge ecore job and txt into ecore?)
Hi there, SVN rev. 45570 merged all of ecore_job into ecore. While I updated everything in our SVN to cope with this change (thanks cedric for catching some of my mistakes), if you're using ecore_job in your projects, you need to update your code. If you were using ecore previously, all you need to do is remove all checks for ecore-job in configure.ac, as well as stop including Ecore_Job.h and stop calling ecore_job_init/ecore_job_shutdown. If you were using only ecore-job, you now need to check for ecore instead of ecore-job, include Ecore.h instead of Ecore_Job.h and call ecore_init/ecore_shutdown instead of ecore_job_init/shutdown Regards, -- Albin Tonnerre -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] SVN cleanup for impending release
On Tue, 02 Feb 2010 18:59 -0200, Gustavo Sverzut Barbieri wrote : What's good in keeping them? SVN's version of Attic? :-) Again, I see no other projects keeping attic stuff... see kde3 stuff, gnome, kernel... once things are gone, they're gone! just svn log will show they ever existed. If you wish we could create a Dead_Projects wiki page and list the revision each directory was removed so one can easily recover it. Yes, please. That would really help. There's no point in keeping dead code around, it just makes things harder for everyone. Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: rui trunk/elmdentica/src
On Sun, 28 Feb 2010 12:07 -0300, Gustavo Sverzut Barbieri wrote : On Sun, Feb 28, 2010 at 11:44 AM, Rui Miguel Silva Seabra r...@1407.org wrote: Em 28-02-2010 14:37, Vaudano Luca escreveu: Just out of curiosity, why is glib not advised? You're taking it the wrong way. The advice was to use the functionality that is in EFL instead of picking up the same functionality from external libraries. Actually some things are not even EFL, but simple POSIX calls like strdup() instead of g_strdup(), asprintf() instead of g_strdup_printf() This not being against fair glib usage, but those are abuses that don't need to exist and Rui kindly fixed those. I wouldn't consider using g_strdup_printf vs. asprintf an abuse. asprint is a GNU-specific extension, and is not guaranteed to be available. g_strdup_printf, OTOH, is part on the glib API, which guarantees that it's available on a fair - and defined - set of plartforms. That being said, please note that I'm not arguing against the change. Regards, -- Albin Tonnerre signature.asc Description: Digital signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Include hour and minute in rpm spec release tags
On Wed, Apr 7, 2010 at 1:27 PM, Rui Miguel Silva Seabra r...@1407.org wrote: Again: I have no intention of treading on your toes, you're making it personal and I have more than once pointed out that there is nothing of the such. I don't think anyone is trying to make it personal. You think that adding HHMM to the spec files would be helpful, Michael doesn't. I guess you'll just have to agree to disagree on this. Cheers, Albin -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] Efreet: move efreet_desktop_cache_create out of the path
This binary is just an internal helper, and isn't expected to be run by anything but efreet. Therefore, let's emphasize this and keep it out of the path by installing it in PACKAGE_LIB_DIR/efreet/ Signed-off-by: Albin Tonnerre lu...@debian.org --- src/bin/Makefile.am |3 ++- src/lib/Makefile.am |2 +- src/lib/efreet_desktop.c |4 ++-- 3 files changed, 5 insertions(+), 4 deletions(-) diff --git a/src/bin/Makefile.am b/src/bin/Makefile.am index a516ebe..71886c1 100644 --- a/src/bin/Makefile.am +++ b/src/bin/Makefile.am @@ -9,7 +9,8 @@ AM_CPPFLAGS = \ -DPACKAGE_DATA_DIR=\$(datadir)/$(PACKAGE)\ \ @EFREET_CFLAGS@ -bin_PROGRAMS = \ +internal_bindir=$(libdir)/efreet +internal_bin_PROGRAMS = \ efreet_desktop_cache_create efreet_desktop_cache_create_LDADD = \ diff --git a/src/lib/Makefile.am b/src/lib/Makefile.am index f3d1c6c..eb4b7fc 100644 --- a/src/lib/Makefile.am +++ b/src/lib/Makefile.am @@ -31,7 +31,7 @@ dist_installed_headers_DATA = $(EFREETHEADERS) Efreet_Mime.h Efreet_Trash.h libefreet_la_SOURCES = $(EFREETSOURCES) libefreet_la_CPPFLAGS = \ -DPACKAGE_DATA_DIR=\$(datadir)\ \ --DPACKAGE_BIN_DIR=\$(bindir)\ \ +-DPACKAGE_LIB_DIR=\$(libdir)\ \ -I$(top_builddir)/src/lib \ -I$(top_srcdir)/src/lib \ @EFL_EFREET_BUILD@ \ diff --git a/src/lib/efreet_desktop.c b/src/lib/efreet_desktop.c index f202f53..06c5779 100644 --- a/src/lib/efreet_desktop.c +++ b/src/lib/efreet_desktop.c @@ -289,7 +289,7 @@ efreet_desktop_init(void) efreet_desktop_listen_changes(); -ecore_exe_run(PACKAGE_BIN_DIR /efreet_desktop_cache_create, NULL); +ecore_exe_run(PACKAGE_LIB_DIR /efreet/efreet_desktop_cache_create, NULL); } @@ -2384,7 +2384,7 @@ efreet_desktop_update_cache_job(void *data __UNUSED__) if (efreet_desktop_exe_lock 0) return; /* TODO: Retry update cache later */ if (flock(efreet_desktop_exe_lock, LOCK_EX | LOCK_NB) 0) goto error; -efreet_desktop_exe = ecore_exe_run(PACKAGE_BIN_DIR /efreet_desktop_cache_create, NULL); +efreet_desktop_exe = ecore_exe_run(PACKAGE_LIB_DIR /efreet/efreet_desktop_cache_create, NULL); if (!efreet_desktop_exe) goto error; return; -- 1.7.0.4 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Dumping Exebuf in favor of Everything?
On Sat, 10 Apr 2010 18:43 -0300, Gustavo Sverzut Barbieri wrote : Hi all, I'd like to call a voting to dump Exebuf and use Everything by default. It is fancier, it is more powerful and i see no reason to not do it. exebuf can be then disabled or just removed from SVN, as well as its conf_exebuf. Speaking of which… I just recompiled from SVN, and everything (which I have been using as a replacement for exebuf for a long time) now uses modules. That's all nice and awesome, but please do enable those modules by default. Updating e17 and not being able to do anything with everything (heh) anymore is just plain annoying. Cheers, -- Albin Tonnerre -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Dumping Exebuf in favor of Everything?
On Sun, 11 Apr 2010 16:19 +0200, hannes.janet...@gmail.com wrote : On Sun, Apr 11, 2010 at 3:04 PM, Albin Tonnerre albin.tonne...@gmail.com wrote: On Sat, 10 Apr 2010 18:43 -0300, Gustavo Sverzut Barbieri wrote : Hi all, I'd like to call a voting to dump Exebuf and use Everything by default. It is fancier, it is more powerful and i see no reason to not do it. exebuf can be then disabled or just removed from SVN, as well as its conf_exebuf. Speaking of which… I just recompiled from SVN, and everything (which I have been using as a replacement for exebuf for a long time) now uses modules. That's all nice and awesome, but please do enable those modules by default. Updating e17 and not being able to do anything with everything (heh) anymore is just plain annoying. The modules are enabled by default in standard profile. Dont know if and how one should update old configs automatically. I know it's possible to add new default values on upgrades, but I don't whether that's also true for modules. Raster: is there any way to make a module automatically loaded when upgrading to a new version ? Regards, -- Albin Tonnerre -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: raster trunk/e/src/bin
On Tue, Apr 27, 2010 at 3:30 PM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: no more e_fm_open - use dbus... eg: dbus-send --session --dest=org.enlightenment.FileManager /org/enlightenment/FileManager org.enlightenment.FileManager.OpenDirectory string:'/home/raster' Author: raster Date: 2010-04-27 06:30:33 -0700 (Tue, 27 Apr 2010) New Revision: 48362 Removed: trunk/e/src/bin/e_fm_open.c Modified: trunk/e/src/bin/e_ipc.c I guess you also need to fix Makefile.am Cheers, Albin -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Insecure SVG loader test
On Sat, 14 Aug 2010 23:13 +0200, Joerg Sonnenberger wrote : hi all, in src/bin/e_main.c there is this wonderful gem _e_main_test_svg_loader. Writting a hard-coded XML file to a known location is just asking for trouble. It basically means that anyone with write access to /tmp can make the E17 user overwrite a file with permissions of the user. It also creates race conditions for multiple users. Thanks for sending this. I think I mentionned it on IRC at one point, and then forgot about it. Any reason why this piece of code is needed at all? That's a little bit complicated: - The freedesktop.org spec says that SVG icons lookup is optional, but if it is supported, then the lookup order is png - svg - xpm - If efreet returns an SVG icon when SVG rendering is not compiled in evas, then you get no icon where an xpm icon (which could have been rendered correctly) might have existed. - Since there is no way to ask evas if SVG support is available (which I think is a mistake), you need to do some kind of runtime detection. - Right now, the only practical way to do that is using some voodoo: create a dummy file and try to load it. To sum it up: it's here because such kind of tests are the only way to check whether Evas supports a particular format. Or at least, so were they when the patch got commited. Cheers, -- Albin Tonnerre -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Insecure SVG loader test
On Sat, 14 Aug 2010 23:46 +0200, Joerg Sonnenberger wrote : On Sat, Aug 14, 2010 at 11:35:13PM +0200, Albin Tonnerre wrote: - If efreet returns an SVG icon when SVG rendering is not compiled in evas, then you get no icon where an xpm icon (which could have been rendered correctly) might have existed. OK - Since there is no way to ask evas if SVG support is available (which I think is a mistake), you need to do some kind of runtime detection. Yes, that's bad. - Right now, the only practical way to do that is using some voodoo: create a dummy file and try to load it. Why not use install the dummy file to a known location and try loading it that way? share/enlightenment/data/icons/dummy.svg or so. I can't recall, and like I said I'd much rather have Evas being able to expose the information. But if it's not going to happen, then the file should either be shipped with e17 or created in a more secure manner (I'd prefer that, but that's a matter of personal taste). Cheers, -- Albin Tonnerre -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Insecure SVG loader test
On Sun, 15 Aug 2010 07:00 +0200, vto...@univ-evry.fr wrote : Quoting Albin Tonnerre albin.tonne...@gmail.com: you can test that only at runtime and not at configure time, as someone can add the svg loader (as a shared lib) after an installation of evas. So it can only be after testing a svg file, I think. There's no doubt about that. The question was whether the test file should be shipped with e17, or created on the fly. In both cases, we end up doing runtime checks though. Cheers, -- Albin Tonnerre -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: lucas IN trunk/embryo/src: bin lib
On Mon, 16 Aug 2010 15:22 -0700, Michael Jennings wrote : On Monday, 16 August 2010, at 19:15:02 (-0300), Lucas De Marchi wrote: 6) i = a == NULL;= i = !a; 7) i = a != NULL;= i = !!a; Those four are valid also for while loops. Eina_Bool func(char *a) { 8)return a == NULL;= return !a; 9)return a != NULL;= return !!a; } int func2(Eina_Bool b) { return 0; } ... char *a; 10) func2(a == NULL); = func2(!a); 11) func2(a != NULL); = func2(!!a); Those significantly reduce readability IMHO. I agree with Michael here. Cheers, -- Albin Tonnerre -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Using -Wall -Wextra -Wno-unused-parameter
On Wed, 18 Aug 2010, Tom Hacohen wrote: On Wed, Aug 18, 2010 at 10:27 PM, Vincent Torri vto...@univ-evry.fr wrote: EFL_COMPILER_FLAG([-Wall]) adds -Wall to CFLAGS m4_ifdef([v_mic] ***) checks if v_mic is used (that is if the micro version of eina is defined. I did that in order to add these flags only when in developper mode (not in release mode) But you can use EFL_COMPILER_FLAG without m4_ifdef. Just like that: EFL_COMPILER_FLAG([-Wall]) Cool. Is there a standard way to choose between developer mode to release mode in autotools? (except for what you did with the versions) Maybe we should consider adding that as well. better ask raster, as i'm not sure exactly which part of the version is not used for the release mode IIRC, v_mic is always used. The development part is v_rev - the current SVN revision, which is m4_undefine'd for releases. Cheers, -- Albin Tonnerre -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: mej IN trunk/eterm: Eterm/src Eterm/utils libast/src libast/test spite
On Mon, 23 Aug 2010 15:28 -0300, Lucas De Marchi wrote : On Mon, Aug 23, 2010 at 2:55 PM, Enlightenment SVN no-re...@enlightenment.org wrote: Log: Revert coccinelle changes. Using !! instead of != NULL results in significantly and unacceptably less readable code, and I refuse to accept those changes. Unfortunately, since they were all done at once, I have to revert the whole thing. Oh well. :( Did you revert the whole thing? Why do you have to do so? At least for EFL, it should be like this as agreed on mailing list / irc The particular change Michael is unhappy with is != NULL = !!, and he did express his disagreement about it (and so did I, FWIW). That being said, I'm not going to fight over it if the general opinion is that it's fine. Cheers, -- Albin Tonnerre -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E SVN: lucas IN trunk: E16/e/src PROTO/eon/src/lib/layout ecore/src/lib/ecore_win32 ecore/src/lib/ecore_wince edje/src/lib evas/src/lib/cache exalt/src/lib
On Fri, 27 Aug 2010 00:08 +0200, Vincent Torri wrote : On Thu, 26 Aug 2010, Michael Jennings wrote: No, that's the whole point. Every instance that was patched needs to be examined and probably fixed. Reverting it doesn't accomplish anything either. that patch is NOT good, hence it should not be in. A mail showing where the problems are, without modifying the code in svn is far way better than committing something wrong. I don't have any strong opinion as to whether this should be reverted or not, but I do agree with Vincent that sending the patch to the ML saying hey, those places probably need fixing would have been a far nicer approach. Cheers, -- Albin Tonnerre -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e install locations
On Mon, 30 Aug 2010 12:39 +0900, Carsten Haitzler wrote : the problem with PREFIX/share/doc is that this will conflict with distro policies on doc dir naming most likely. distros like debian and ubuntu qand that docdir to be the package name. almost nothing installs docs from src that i know of, so packagers populate those doc dirs with a set of standard files etc. from the src tree in a standard way. the alternative will be yet another flame-fest involving debian and ubuntu and other distro packagers and their policies and them having to patch e's build scripts/makeifles to not conflict with distro policies. As the maintainer of the Debian packages, I'm not going to start any flamewar. Even better: I agree with Michael here, and think that this move would make sense. Cheers, -- Albin Tonnerre -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] [PATCH] eina-1.7: allow running the testsuite independantly of coverage support
It used to be possible to run the testsuite whether coverage was enabled or not; this is very useful for eg. distros who want to automatically run the testsuite without having to compile with coverage support. Most other EFL in the stable branch already allow this (evas, ecore, edje); update Eina to bring it in line with them. --- Makefile.am | 29 - configure.ac | 10 +++- m4/common/efl_coverage.m4 | 62 + m4/common/efl_tests.m4| 27 +++- 4 files changed, 97 insertions(+), 31 deletions(-) create mode 100644 m4/common/efl_coverage.m4 diff --git a/Makefile.am b/Makefile.am index 5ff1896..e67c183 100644 --- a/Makefile.am +++ b/Makefile.am @@ -42,7 +42,8 @@ m4/common/efl_attribute.m4 \ m4/common/efl_benchmark.m4 \ m4/common/efl_check_funcs.m4 \ m4/common/efl_compiler_flag.m4 \ -m4/common/efl_cpu.m4 \ +m4/common/efl_coverage.m4 \ +m4/common/efl_cpu.m4\ m4/common/efl_doxygen.m4 \ m4/common/efl_examples.m4 \ m4/common/efl_path_max.m4 \ @@ -68,6 +69,20 @@ install-doc: if EFL_ENABLE_TESTS +check-local: + @./src/tests/eina_suite + +else + +check-local: + @echo reconfigure with --enable-tests + +endif + +# Coverage report + +if EFL_ENABLE_COVERAGE + lcov-reset: @rm -rf $(top_builddir)/coverage @find $(top_builddir) -name *.gcda -delete @@ -80,21 +95,21 @@ lcov-report: genhtml -t $(PACKAGE_STRING) -o $(top_builddir)/coverage/html $(top_builddir)/coverage/coverage.cleaned.info @echo Coverage Report at $(top_builddir)/coverage/html -check-local: +coverage: @$(MAKE) lcov-reset - @./src/tests/eina_suite + @$(MAKE) check @$(MAKE) lcov-report else lcov-reset: - @echo reconfigure with --enable-tests + @echo reconfigure with --enable-coverage lcov-report: - @echo reconfigure with --enable-tests + @echo reconfigure with --enable-coverage -check-local: - @echo reconfigure with --enable-tests +coverage: + @echo reconfigure with --enable-tests --enable-coverage endif diff --git a/configure.ac b/configure.ac index d132d15..1775f0e 100644 --- a/configure.ac +++ b/configure.ac @@ -553,6 +553,14 @@ EINA_CHECK_MODULE([one-big],[${enable_one_big}], [one big]) EFL_CHECK_TESTS([eina], [enable_tests=yes], [enable_tests=no]) +EFL_CHECK_COVERAGE([${enable_tests}], [enable_coverage=yes], [enable_coverage=no]) +EINA_CFLAGS=${EINA_CFLAGS} ${EFL_COVERAGE_CFLAGS} ${EXOTIC_CFLAGS} +EINA_LIBS=${EINA_LIBS} ${EFL_COVERAGE_LIBS} ${EXOTIC_LIBS} +if test x$enable_coverage = xyes ; then + EINA_CFLAGS=${EINA_CFLAGS} ${EFL_DEBUG_CFLAGS} +fi + + EFL_CHECK_BENCHMARK([enable_benchmark=yes], [enable_benchmark=no]) EINA_BENCH_MODULE([glib], [${enable_benchmark}], [glib-2.0], [enable_benchmark_glib=yes], [enable_benchmark_glib=no]) if test -n $CXX test x$enable_benchmark = xyes ; then @@ -628,7 +636,7 @@ echo Documentation: ${build_doc} if test x${build_doc} = xyes ; then echo Installation...: make install-doc fi -echo Tests: ${enable_tests} (Coverage: ${efl_enable_coverage}) +echo Tests: ${enable_tests} (Coverage: ${enable_coverage}) echo Examples.: ${enable_build_examples} echo Tiler Example: ${build_tiler_example} echo Examples installed...: ${enable_install_examples} diff --git a/m4/common/efl_coverage.m4 b/m4/common/efl_coverage.m4 new file mode 100644 index 000..85d0321 --- /dev/null +++ b/m4/common/efl_coverage.m4 @@ -0,0 +1,62 @@ +dnl Copyright (C) 2008 Vincent Torri vtorri at univ-evry dot fr +dnl That code is public domain and can be freely used or copied. + +dnl Macro that check if coverage support is wanted and, if yes, if +dnl lcov is available. + +dnl Usage: EFL_CHECK_COVERAGE(tests [, ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]]) +dnl The parameter 'tests' is used if a dependency is needed. If set to yes, +dnl the dependency is available. +dnl Defines EFL_COVERAGE_CFLAGS and EFL_COVERAGE_LIBS variables +dnl Defines the automake conditionnal EFL_ENABLE_COVERAGE + +AC_DEFUN([EFL_CHECK_COVERAGE], +[ + +dnl configure option + +AC_ARG_ENABLE([coverage], + [AC_HELP_STRING([--enable-coverage], [enable coverage profiling instrumentation @:@default=disabled@:@])], + [ +if test x${enableval} = xyes ; then + _efl_enable_coverage=yes +else + _efl_enable_coverage=no +fi + ], + [_efl_enable_coverage=no]) + +AC_MSG_CHECKING([whether to use profiling instrumentation]) +AC_MSG_RESULT([$_efl_enable_coverage]) + +dnl lcov check + +if test x$_efl_enable_coverage = xyes test ! x$1 = xyes ; then + AC_MSG_WARN([Coverage report requested but tests not being built, disable profiling instrumentation.]) + AC_MSG_WARN([Run configure with --enable-tests]) + _efl_enable_coverage=no +fi + +if test x$_efl_enable_coverage = xyes ; then +
[E-devel] [PATCH] e17: use #!/bin/bash for e_remote since it uses bash-specific features
enlightenment_remote uses at least variable substitution (${var%%.*}) and options (echo -e) that are not guaranteed to be available in stricter (wrt. what's in POSIX) shell implementations, which may lead to malfunction. Running the script using bash ensures things work as intended. --- data/tools/enlightenment_remote |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/data/tools/enlightenment_remote b/data/tools/enlightenment_remote index 45295bb..a5e5d74 100644 --- a/data/tools/enlightenment_remote +++ b/data/tools/enlightenment_remote @@ -1,4 +1,4 @@ -#!/bin/sh +#!/bin/bash # # See the function show_help_new_tool in order to know more about this tool -- 1.7.10.4 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] e17: use #!/bin/bash for e_remote since it uses bash-specific features
On Sat, Dec 29, 2012 at 6:30 PM, Brian 'morlenxus' Miculcy morlen...@gmx.net wrote: Hm, i suggest to use #!/usr/bin/env bash The common usage for shell scripts seems to be /bin/$SHELL (since unlike perl or python there tends not be several competing versions of a given shell interpreter), but feel free to use whatever you think is appropriate :) Cheers, -- Albin -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] eina-1.7: allow running the testsuite independantly of coverage support
On Sat, Dec 29, 2012 at 2:49 PM, Albin Tonnerre albin.tonne...@gmail.com wrote: It used to be possible to run the testsuite whether coverage was enabled or not; this is very useful for eg. distros who want to automatically run the testsuite without having to compile with coverage support. Most other EFL in the stable branch already allow this (evas, ecore, edje); update Eina to bring it in line with them. I kind of expected our beloved autofoo maintainer to apply that patch, but sadly he has resigned since... Anybody brave enough to pick it up (or at least comment) ? Thanks, -- Albin -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Fun with 0.17.0
On Fri, Jan 4, 2013 at 10:34 AM, Carsten Haitzler ras...@rasterman.com wrote: we upgraded major config version for e17 - thus yes - it gets wiped. Just curious - what was the particular change that required the config to get wiped? Thanks, -- Albin -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [PATCH] e17: use #!/bin/bash for e_remote since it uses bash-specific features
On Sun, Dec 30, 2012 at 5:14 AM, P Purkayastha ppu...@gmail.com wrote: Are you sure variable substitution (using #, %, etc) is not POSIX? As far I could remember, it is POSIX. I also found it mentioned here, and a couple of other places on Google search: I stand corrected :) Looks like some other forms of variable substitutions aren't in POSIX, but the ones we use actually are. Thanks for pointing this out. There are only two lines in enlightenment_remote which use echo -e and I think in both the lines they are unnecessary. True. I have a couple other patches fixing issues in Eet, I guess I'll just send a patch dropping the echo -e along with that. Cheers, -- Albin -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Eet testsuite failures
Hi, I recently uploaded Eet 1.7.4 to Debian; this was the first version to have the testsuite enabled and to my suprise, it failed on all bigendian architectures (https://buildd.debian.org/status/package.php?p=eetsuite=experimental) I tried to find the cause of the issue, and it would seem there's a code path in eet_data_image_lossless_compressed_convert that fails to appropriately convert the input data to little endian before compressing it; this data is then uncompressed in _eet_data_image_decode_inside and, on bigend machines, converted back to bigend which obviously yields incorrect results. I've used the following patch to solve the issue, but since I'm no eet expert I'd gladly appreciate any input :) diff --git a/src/lib/eet_image.c b/src/lib/eet_image.c index 7116a3c..5a37bf2 100644 --- a/src/lib/eet_image.c +++ b/src/lib/eet_image.c @@ -746,13 +746,26 @@ eet_data_image_lossless_compressed_convert(int *size, { unsigned char *d, *comp; - int *header, ret, ok = 1; + int *header, *bigend_data, ret, ok = 1; uLongf buflen = 0; buflen = (((w * h * 101) / 100) + 3) * 4; ret = LZ4_compressBound((w * h * 4)); if ((ret 0) ((uLongf)ret buflen)) buflen = ret; - + + if (_eet_image_words_bigendian) +{ + int i; + int *bigend_data = (int *) malloc(w * h * 4); + + if (!bigend_data) return NULL; + + memcpy(bigend_data, data, w * h * 4); + for (i = 0; i w * h; i++) SWAP32(bigend_data[i]); + + data = (const char *) bigend_data; +} + comp = malloc(buflen); if (!comp) return NULL; @@ -803,6 +816,7 @@ eet_data_image_lossless_compressed_convert(int *size, unsigned int i; for (i = 0; i 8; i++) SWAP32(header[i]); + free(bigend_data); } memcpy(d + (8 * sizeof(int)), comp, buflen); On a related matter, the testsuite also dies with SIGBUS on SPARC due to what seems to be an arbitrarily-aligned void* used as an int* in eet_cipher. The following patch fixes the issue for me: diff --git a/src/lib/eet_cipher.c b/src/lib/eet_cipher.c index 3317538..4e1433c 100644 --- a/src/lib/eet_cipher.c +++ b/src/lib/eet_cipher.c @@ -706,9 +706,13 @@ eet_identity_check(const void *data_base, return NULL; /* Get the header */ - magic = ntohl(header[0]); - sign_len = ntohl(header[1]); - cert_len = ntohl(header[2]); + memcpy(magic,header, sizeof(int)); + memcpy(sign_len, header+1, sizeof(int)); + memcpy(cert_len, header+2, sizeof(int)); + + magic = ntohl(magic); + sign_len = ntohl(sign_len); + cert_len = ntohl(cert_len); /* Verify the header */ if (magic != EET_MAGIC_SIGN) Please let me know if you want me to rework the patches, submit them with ChangeLog entries for the stable releases or whatever :) Cheers, -- Albin -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eet testsuite failures
On Wed, Jan 9, 2013 at 1:27 AM, Leandro Dorileo dori...@profusion.mobi wrote: Hi, { unsigned char *d, *comp; - int *header, ret, ok = 1; + int *header, *bigend_data, ret, ok = 1; uLongf buflen = 0; buflen = (((w * h * 101) / 100) + 3) * 4; ret = LZ4_compressBound((w * h * 4)); if ((ret 0) ((uLongf)ret buflen)) buflen = ret; - + + if (_eet_image_words_bigendian) +{ + int i; + int *bigend_data = (int *) malloc(w * h * 4); Shadowed declaration of bigend_data here. Oops, correct. That must have crept in while doing some refactoring :) Obvisouly the first declaration is the one we need to keep, since we free the pointer later on. -- Albin -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Eet testsuite failures
On Tue, Jan 8, 2013 at 11:18 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Hi Lutin, both seem correct to me. Let's wait for others to chime in, but they should be okay. I'd like to upload those fixes to Debian soon, so now would be a good time for anyone who'd like to object :) -- Albin -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[EGIT] [core/efl] master 01/01: ecore_x/xlib/ecore_x_vsync.c uses dlopen and dlsym, but configure.ac only checks for this for the XCB variant. This results in linker errors when using strict linker fl
yoz pushed a commit to branch master. http://git.enlightenment.org/core/efl.git/commit/?id=6b130d8b18e5077f4a5fe0fefe534a73053fcb08 commit 6b130d8b18e5077f4a5fe0fefe534a73053fcb08 Author: Albin Tonnerre lu...@debian.org Date: Tue Oct 29 23:25:54 2013 +0100 ecore_x/xlib/ecore_x_vsync.c uses dlopen and dlsym, but configure.ac only checks for this for the XCB variant. This results in linker errors when using strict linker flags (-Wl,-z,defs) --- configure.ac | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configure.ac b/configure.ac index 2060040..413264a 100644 --- a/configure.ac +++ b/configure.ac @@ -2772,6 +2772,9 @@ if test x${want_x11_xlib} = xyes ; then AC_DEFINE([HAVE_ECORE_X_XLIB], [1], [Defined to 1 if Xlib is enabled.]) HAVE_ECORE_X_BACKEND=HAVE_ECORE_X_XLIB + + EFL_EVAL_PKGS([ECORE_X]) + EFL_CHECK_FUNCS([ECORE_X], [dlopen dlsym]) fi ## XCB --
[EGIT] [legacy/eina] eina-1.7 01/01: Tests: Link against @EFL_PTHREAD_LIBS@
etrunko pushed a commit to branch eina-1.7. http://git.enlightenment.org/legacy/eina.git/commit/?id=13eb61dacb2cabcc8a5d2fd29703759f69df5c0e commit 13eb61dacb2cabcc8a5d2fd29703759f69df5c0e Author: Albin Tonnerre lu...@debian.org Date: Fri Nov 1 11:25:11 2013 -0200 Tests: Link against @EFL_PTHREAD_LIBS@ Signed-off-by: Eduardo Lima (Etrunko) eduardo.l...@intel.com --- src/tests/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/tests/Makefile.am b/src/tests/Makefile.am index cc37476..f6e7f6b 100644 --- a/src/tests/Makefile.am +++ b/src/tests/Makefile.am @@ -70,7 +70,7 @@ eina_test_simple_xml_parser.c \ eina_test_value.c # eina_test_model.c -eina_suite_LDADD = @CHECK_LIBS@ $(top_builddir)/src/lib/libeina.la @EINA_LIBS@ -lm +eina_suite_LDADD = @CHECK_LIBS@ $(top_builddir)/src/lib/libeina.la @EINA_LIBS@ @EFL_PTHREAD_LIBS@ -lm cxx_compile_test_SOURCES = cxx_compile_test.cxx cxx_compile_test_LDADD = $(top_builddir)/src/lib/libeina.la @EINA_LIBS@ --
[E-devel] ECORE_EVAS_EXTN_CLIENT_ADD / ECORE_EVAS_EXTN_CLIENT_DEL
Hi, I noticed something strange while working on the Debian packaging for EFL 1.8: the two symbols mentionned in the title are no longer present in libecore-evas.so but are apparently part of the API: they're exported in Ecore_Evas.h Those two variables seem to have been moved to a module by commit 85f8163c3ee5b5d776d94c70ff9fbc667a615b2a , but as far a I can tell moving the actual symbols in an Ecore_Evas module effectively breaks the ABI: any library or application that used this variable will fail to load because the symbols can't be resolved. Similarly, it's not possible to use them in an application since the symbol can't be resolved at link time. Does anyone know what to make of this? Thanks, -- Albin -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel