[E-devel] opensuse 11.0 package dependency failures for libecore0.so.0
Devs, Hello. Good to be with you guys after finding enlightenment. I have a problems with and install of e17 packages from an openSuSE repository and I suspect the issue is a missing link in the libecore package to libecore0.so.0. I rebuilt the source rpm for libecore to see what was happening. Built fine. The present libecore package in the prepository provides: /usr/lib64/libecore-ver-pre-svn-04.so.0 /usr/lib64/libecore-ver-pre-svn-04.so.0.9.9 /usr/lib64/libecore_con-ver-pre-svn-04.so.0 /usr/lib64/libecore_con-ver-pre-svn-04.so.0.9.9 /usr/lib64/libecore_config-ver-pre-svn-04.so.0 /usr/lib64/libecore_config-ver-pre-svn-04.so.0.9.9 /usr/lib64/libecore_evas-ver-pre-svn-04.so.0 /usr/lib64/libecore_evas-ver-pre-svn-04.so.0.9.9 /usr/lib64/libecore_file-ver-pre-svn-04.so.0 /usr/lib64/libecore_file-ver-pre-svn-04.so.0.9.9 /usr/lib64/libecore_imf-ver-pre-svn-04.so.0 /usr/lib64/libecore_imf-ver-pre-svn-04.so.0.9.9 /usr/lib64/libecore_imf_evas-ver-pre-svn-04.so.0 /usr/lib64/libecore_imf_evas-ver-pre-svn-04.so.0.9.9 /usr/lib64/libecore_input-ver-pre-svn-04.so.0 /usr/lib64/libecore_input-ver-pre-svn-04.so.0.9.9 /usr/lib64/libecore_ipc-ver-pre-svn-04.so.0 /usr/lib64/libecore_ipc-ver-pre-svn-04.so.0.9.9 /usr/lib64/libecore_job-ver-pre-svn-04.so.0 /usr/lib64/libecore_job-ver-pre-svn-04.so.0.9.9 /usr/lib64/libecore_sdl-ver-pre-svn-04.so.0 /usr/lib64/libecore_sdl-ver-pre-svn-04.so.0.9.9 /usr/lib64/libecore_txt-ver-pre-svn-04.so.0 /usr/lib64/libecore_txt-ver-pre-svn-04.so.0.9.9 /usr/lib64/libecore_x-ver-pre-svn-04.so.0 /usr/lib64/libecore_x-ver-pre-svn-04.so.0.9.9 /usr/share/locale/fr/LC_MESSAGES/ecore.mo /usr/share/locale/it/LC_MESSAGES/ecore.mo The error for many of the packages concerning the dependency conflict is: libecore.so.0 needed by entropy-svn_20090309_r39423-2.2.i586, nothing provides libecore.so.0: [ ] Do not install entropy-svn_20090309_r39423-2.2.i586 The same thing happens for: elementary-sms-20091012_r43036-1.1.i586.rpm epdf-svn_20090309_r39423-2.1.i586.rpm ephoto-svn_20090914_r42487-1.5.i586.rpm snip Could this simply be a missing sym link for libecore.so.0 to libecore-ver- pre-svn-04.so.0?? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eina stringshare thread safe
actually all eina should be thread safe. Maybe eet and ecore too. If you are not against this I will start to work on eina. 2009/10/25 Gustavo Sverzut Barbieri barbi...@profusion.mobi On Sun, Oct 25, 2009 at 5:20 PM, Atton Jonathan jonathan.at...@gmail.com wrote: hey, I talked a week ago with cedric about making eina stringshare thread safe. The mutex could be activated/deactivated with a classic function and then 2 macros will be use: LOCK : if(mutex_activated) pthread_mutex_lock() UNLOCK : if(mutex_activated) pthread_mutex_unlock() By default the mutex can be deactivated and the developer activate it if necessary. What do you think about this idea ? The only problem with this is inconsistency. Okay, we have stringshare as this, but still default mempool is not so you cannot allocate list nodes... then you cannot add ecore idlers/timers/pollers/... from threads, and so on. Inconsistency is bad :-( I really don't see any clear solution to this problem. Maybe we could have something like glib's threads init. I have this for logging, but i was really reluctant to add it. But if so, then we must make sure all types would be thread safe. BR, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Regards. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] eina stringshare thread safe
On Mon, Oct 26, 2009 at 1:07 PM, Atton Jonathan jonathan.at...@gmail.com wrote: actually all eina should be thread safe. Maybe eet and ecore too. If you are not against this I will start to work on eina. Actually, I think we should do this really carefully. I think we should make stringshare thread safe, because their is no way from an user API point of view to use them without messing everything from another thread. So i agree we will need something like 'int eina_thread_safe_init(void)' and 'int eina_thread_safe_shutdown(void)', that track the number of time an user need to be safe and set one global flag that activate some mutex for stringshare. But I don't want to see eina_list or eina_hash, add some pthread lock just because the user can't do it by itself. And in most case, he will be able to do it much more efficiently than we could in eina. 2009/10/25 Gustavo Sverzut Barbieri barbi...@profusion.mobi On Sun, Oct 25, 2009 at 5:20 PM, Atton Jonathan jonathan.at...@gmail.com wrote: hey, I talked a week ago with cedric about making eina stringshare thread safe. The mutex could be activated/deactivated with a classic function and then 2 macros will be use: LOCK : if(mutex_activated) pthread_mutex_lock() UNLOCK : if(mutex_activated) pthread_mutex_unlock() By default the mutex can be deactivated and the developer activate it if necessary. What do you think about this idea ? The only problem with this is inconsistency. Okay, we have stringshare as this, but still default mempool is not so you cannot allocate list nodes... then you cannot add ecore idlers/timers/pollers/... from threads, and so on. Inconsistency is bad :-( The default mempool is thread safe. Definitivly, it should work safely if you build eina with pthread support. If not, it's a bug that should be fixed. For ecore, this is another matter, right now, by design we don't want to I really don't see any clear solution to this problem. Maybe we could have something like glib's threads init. I have this for logging, but i was really reluctant to add it. But if so, then we must make sure all types would be thread safe. So maybe when thread safe is required do the same trick for eina_log to. -- Cedric BAIL -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Patch for evas (eina_log related)
On Thursday 22 October 2009 09:23:13 Mathieu Taillefumier wrote: It seems that my previous email did not pass through the mailing list. herewith a patch for evas that modify the previous patch I send weeks ago. The changes are listed below - Conversion of the remaining printf to eina_log in the lib and bin directories - Correction of the macros ERROR to ERR that caused trouble on windows platform. Now everything follow the short naming convention - Conversion of the printf in the graphical engines. The loaders are let as it is. the only thing that is problematic (maybe) is the initialization of the log domains for the engines. It is located in the module_open() (module_close() for destroying it) function. unfortunately, this looks like it broke directfb and qtopia. + _evas_engine_directfb_log_dom = eina_log_domain_register(EvasEngineDirectFB,EVAS_DEFAULT_COLOR); + _evas_engine_soft_qtopia_log_dom = eina_log_domain_register(EvasSoftQtopia,EVAS_DEFAULT_COLOR); ive fixed it now, but please try to test all your changes -mike signature.asc Description: This is a digitally signed message part. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Screen rotation and show/hide gadgets cause a segv
To produce this bug I started enlightenment in Xephyr. I then locked the keyboard and mouse to the Xephyr window and pressed Ctrl-Alt-G to show the gadgets and again to hide them. I then rotated the screen using the enlightenment screen settings panel, and ussed Ctrl-Alt-G again. This caused the following segv backtrace and corrosponding output. E17 INIT: XINERAMA SCREEN: [0], 480x640+0+0 E17 INIT: XINERAMA CHOSEN: [0], 480x640+0+0 Sending TERM signal to /usr/lib/enlightenment/modules/temperature/linux-gnu-i686-ver-pre-svn-04/tempget 0 (null) 128 (16846). Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb6d566c0 (LWP 16844)] 0xb738c04e in evas_object_type_get () from /usr/lib/libevas-ver-pre-svn-04.so.0 (gdb) backtrace #0 0xb738c04e in evas_object_type_get () from /usr/lib/libevas-ver-pre-svn-04.so.0 #1 0xb762a9b5 in _edje_fetch () from /usr/lib/libedje-ver-pre-svn-04.so.0 #2 0xb7626650 in edje_object_signal_emit () from /usr/lib/libedje-ver-pre-svn-04.so.0 #3 0xb6883176 in gadman_gadgets_show () from /usr/lib/enlightenment/modules/gadman/linux-gnu-i686-ver-pre-svn-04/module.so #4 0xb6883226 in gadman_gadgets_toggle () from /usr/lib/enlightenment/modules/gadman/linux-gnu-i686-ver-pre-svn-04/module.so #5 0xb68817e7 in ?? () from /usr/lib/enlightenment/modules/gadman/linux-gnu-i686-ver-pre-svn-04/module.so #6 0xb68817d9 in ?? () from /usr/lib/enlightenment/modules/gadman/linux-gnu-i686-ver-pre-svn-04/module.so #7 0x0978a9b8 in ?? () #8 0xbf86e2a8 in ?? () #9 0x080bcada in e_bindings_key_down_event_handle () Backtrace stopped: frame did not save the PC -- John C. Kha -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Screen rotation and show/hide gadgets cause a segv
Compile gadman, evas and edje with the debug mode (-g) and then re do a backtrace please 2009/10/26 John Kha sir...@gmail.com To produce this bug I started enlightenment in Xephyr. I then locked the keyboard and mouse to the Xephyr window and pressed Ctrl-Alt-G to show the gadgets and again to hide them. I then rotated the screen using the enlightenment screen settings panel, and ussed Ctrl-Alt-G again. This caused the following segv backtrace and corrosponding output. E17 INIT: XINERAMA SCREEN: [0], 480x640+0+0 E17 INIT: XINERAMA CHOSEN: [0], 480x640+0+0 Sending TERM signal to /usr/lib/enlightenment/modules/temperature/linux-gnu-i686-ver-pre-svn-04/tempget 0 (null) 128 (16846). Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb6d566c0 (LWP 16844)] 0xb738c04e in evas_object_type_get () from /usr/lib/libevas-ver-pre-svn-04.so.0 (gdb) backtrace #0 0xb738c04e in evas_object_type_get () from /usr/lib/libevas-ver-pre-svn-04.so.0 #1 0xb762a9b5 in _edje_fetch () from /usr/lib/libedje-ver-pre-svn-04.so.0 #2 0xb7626650 in edje_object_signal_emit () from /usr/lib/libedje-ver-pre-svn-04.so.0 #3 0xb6883176 in gadman_gadgets_show () from /usr/lib/enlightenment/modules/gadman/linux-gnu-i686-ver-pre-svn-04/module.so #4 0xb6883226 in gadman_gadgets_toggle () from /usr/lib/enlightenment/modules/gadman/linux-gnu-i686-ver-pre-svn-04/module.so #5 0xb68817e7 in ?? () from /usr/lib/enlightenment/modules/gadman/linux-gnu-i686-ver-pre-svn-04/module.so #6 0xb68817d9 in ?? () from /usr/lib/enlightenment/modules/gadman/linux-gnu-i686-ver-pre-svn-04/module.so #7 0x0978a9b8 in ?? () #8 0xbf86e2a8 in ?? () #9 0x080bcada in e_bindings_key_down_event_handle () Backtrace stopped: frame did not save the PC -- John C. Kha -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Regards. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
