Re: [E-devel] 1.9.0-beta2 pre-release
Stefan Schmidt schrieb: https://phab.enlightenment.org/phame/post/view/38/ We are happy to release the second beta release for the upcoming 1.9 series. This is most likely the final beta2 release before the release happening next week. Please give it a good testing. Download LINKSHA256 efl-1.9.0-beta2.tar.gz ff4037cc3ae45fc5f66cdec7c56de2c6892faf2981f33a89550609831ee8edd1 elementary-1.9.0-beta2.tar.gz 4fd94bbb51793d98922b05f6cd6fc6ff703d49f2b1cef1d25a7ff2d48aa4f146 emotion_generic_players-1.9.0-beta2.tar.gz 57e1251cbc8b4b3bc61c9b864be8ec17377749c98ba777671ff2686406006be1 evas_generic_loaders-1.9.0-beta2.tar.gz b7199c12cabd854da9a3963c6b2be65fde123a40989de22a12f13749b4c96776 Building and Dependencies If you have an existing EFL or Elementary install, you may wish to delete its header files and libraries before compiling and installing to avoid possible conflicts during compilation. If you are compiling the above, please compile them in the following order: efl elementary emotion_generic_players evas_generic_loaders Please refer to the respective README files in each release for a full list of dependencies, explanations on configure flags and other relevant information (Just scroll down to see the README already displayed nicely). EFL Elementary Emotion Generic Players Evas Generic Loaders Recommended dependencies are for all of the above are: luajit (optional lua 5.1 or 5.2) Is this just recommended or a new required dependency for efl-1.9? configure now requires luajit for me and i dont see any switch to disable this additional required dependency. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] 1.9.0-beta2 pre-release
Doug Newgard schrieb: Date: Fri, 21 Feb 2014 17:38:34 +0100 From: to...@gentoo.org To: enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] 1.9.0-beta2 pre-release Stefan Schmidt schrieb: https://phab.enlightenment.org/phame/post/view/38/ We are happy to release the second beta release for the upcoming 1.9 series. This is most likely the final beta2 release before the release happening next week. Please give it a good testing. Download LINK SHA256 efl-1.9.0-beta2.tar.gz ff4037cc3ae45fc5f66cdec7c56de2c6892faf2981f33a89550609831ee8edd1 elementary-1.9.0-beta2.tar.gz 4fd94bbb51793d98922b05f6cd6fc6ff703d49f2b1cef1d25a7ff2d48aa4f146 emotion_generic_players-1.9.0-beta2.tar.gz 57e1251cbc8b4b3bc61c9b864be8ec17377749c98ba777671ff2686406006be1 evas_generic_loaders-1.9.0-beta2.tar.gz b7199c12cabd854da9a3963c6b2be65fde123a40989de22a12f13749b4c96776 Building and Dependencies If you have an existing EFL or Elementary install, you may wish to delete its header files and libraries before compiling and installing to avoid possible conflicts during compilation. If you are compiling the above, please compile them in the following order: efl elementary emotion_generic_players evas_generic_loaders Please refer to the respective README files in each release for a full list of dependencies, explanations on configure flags and other relevant information (Just scroll down to see the README already displayed nicely). EFL Elementary Emotion Generic Players Evas Generic Loaders Recommended dependencies are for all of the above are: luajit (optional lua 5.1 or 5.2) Is this just recommended or a new required dependency for efl-1.9? configure now requires luajit for me and i dont see any switch to disable this additional required dependency. -- Thomas Sachau Gentoo Linux Developer --enable-lua-old should get you 5.1/5.2 support instead of luajit. Don't know why you would want to, but there it is. So some lua is now an additional required dependency, being it either lua-5.1/5.1 or luajit for 1.9? -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] 1.9.0-alpha1 Pre-release: EFL, Elementary, Evas_Generic_Loaders, Emotion_Generic_Players
Jeff Hoogland schrieb: Can I make a request that once the 1.9.x branch makes it to a stable release we keep all components at the same version number like had been done for 1.7.x in the past? Having 1.8.x at three different version numbers is a pain to keep track of packagingwise. Well, let me make a request to continue avoiding useless work for packagers, since a version bump of a package without any content changes just means additional work and useless rebuild without any additional gain. Having to bump for no reason is a pain packaingwise, how different version numbers do make it harder for you is a secret to me, maybe you will share it some day. ;-) -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Enlightenment-release] Upcoming 1.8.x releases on Friday
Stefan Schmidt schrieb: Hello. On Mon, 2013-12-09 at 20:48, Simon wrote: On 12/09/2013 08:33 PM, Stefan Schmidt wrote: Hello. On Mon, 2013-12-09 at 20:05, Simon wrote: On 12/09/2013 05:40 PM, Stefan Schmidt wrote: Hello. On Sun, 2013-12-08 at 14:58, Jeff Hoogland wrote: Just wanted to confirm emotion generic players isn't getting a 1.8.1 release. Confirmed. Emotion generic players had not a single commit since 1.8.0. Nothing to release. regards Stefan Schmidt From a packagers perspective it would be great if we could keep the efl, elementary and evas/emotion_generic_loaders version numbers the same even if there are no changes, the same as we did for the 1.7 tree. I'll leave it for you guys to decide though. I was pondering about that. For 1.7.x we had way more tarballs for one release. Due to the merged efl tree this really got down. Would you expect emotion generic player release tarballs for 1.8.1 and 1.8.2 even when not a single commit hit that repo? We can switch back to that model but I'm not a fan of doing empty releases just to stay in sync for the version number. It would only heppen from 1.8.3 though. Skipping a minor release for everything but efl. IT will always be out of sync with e18 in any case. In sumarry I have no hard feeling in any direction. :) regards Stefan Schmidt I wasn't much of a fan of the empty releases at first either, but realistic the enlightenment foundation libraries are efl, elementary and e*_generic_loaders, its just some components are built separately because its easier and others due to licensing. From a user perspective particularly in regards to filing bugs it makes it easier if they all follow the same versioning, especially if efl and elementary are out of sync. We did it with 1.7.x and its seems to make packagers life easier as well as versions for bug reports, etc. So be it. From 1.8.3 I will do collective releases for efl, elm, evas and emotion generic loaders. Even if the specific tarballs have no changes. regards Stefan Schmidt How does it make packagers life easier, if there are empty version bumps, which also need to be followed by the package manager? From my experience as a packager, it only means more work for no gain, since the content is the same. So as an experience result of the 1.7 series and to avoid wasting time for everyone, i strongly object against doing empty releases again. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Enlightenment-release] Releases pending
Thomas Sachau schrieb:
Eduardo Lima (Etrunko) schrieb:
Fresh new Enlightenment and Elementary. Also, not so new Ecore which
was not sent to the ML.
The black screen with old config still exists.
Also attached a bt full from a segfault with the pre-release of e17
--
Thomas Sachau
Gentoo Linux Developer
#0 0x7f0787a9d66d in pause () at ../sysdeps/unix/syscall-template.S:81
No locals.
#1 signal handler called
No locals.
#2 0x7f0789f3882f in e_border_hide (bd=0x7f078bfff5d0, manage=1) at
e_border.c:1098
visible = optimized out
#3 0x7f0789f38ccd in e_border_desk_set (bd=0x7f078bfff5d0, desk=optimized
out) at e_border.c:994
ev = 0x7f078bf702a0
old_desk = 0x7f078bdd5990
#4 0x7f07767be1c2 in _pager_desk_switch (pd2=0x7f078c897760,
pd1=optimized out) at pager/e_mod_main.c:584
c = optimized out
zone1 = 0x7f078bf6d6b0
desk2 = 0x7f078bdd5990
zone2 = 0x7f078be3b470
desk1 = 0x7f078bf5e030
pw = optimized out
l = 0x7f078c2fb400
#5 _pager_desk_switch (pd1=optimized out, pd2=0x7f078c897760) at
pager/e_mod_main.c:559
No locals.
#6 0x7f07767be44d in _pager_desk_cb_drag_finished (drag=optimized out,
dropped=optimized out) at pager/e_mod_main.c:2369
pd = 0x7f078ce2b5e0
pd2 = optimized out
l = optimized out
desk = optimized out
zone = optimized out
p = optimized out
#7 0x7f0789f5ccfd in _e_drag_end (y=610, x=789, root=optimized out) at
e_dnd.c:988
h = optimized out
dropped = optimized out
zone = optimized out
dx = 870
tmp = optimized out
l = optimized out
ev = {data = 0x7f078ca23260, x = -81, y = -467}
dy = 1077
win = 44040203
ignore_win = {9583052, 9583067}
#8 _e_dnd_cb_mouse_up (event=optimized out, data=optimized out,
type=optimized out) at e_dnd.c:1174
No locals.
#9 _e_dnd_cb_mouse_up (data=optimized out, type=optimized out,
event=optimized out) at e_dnd.c:1167
ev = optimized out
#10 0x7f078974c8d0 in _ecore_call_handler_cb (event=optimized out,
type=optimized out, data=optimized out, func=optimized out)
at ecore_private.h:335
r = optimized out
#11 _ecore_event_call () at ecore_events.c:559
ret = 7 '\a'
e = 0x7f078d1c5980
handle_count = 6
l = optimized out
eh = 0x7f078bee9fb0
#12 0x7f078975174c in _ecore_main_loop_iterate_internal (once_only=0) at
ecore_main.c:1932
next_time = optimized out
#13 0x7f0789751cb7 in ecore_main_loop_begin () at ecore_main.c:956
No locals.
#14 0x7f0789f1c2ac in main (argc=optimized out, argv=optimized out) at
e_main.c:1061
safe_mode = 0 '\000'
after_restart = 1 '\001'
waslocked = 0 '\000'
t = 1380882290.8028769
tstart = 1380882290.8028769
s = optimized out
buff =
1380882290.8\000\177\000\000\000\000\000\000\000\000\000\000?)\361\211\a\177\000
action = {__sigaction_handler = {sa_handler = 0x7f0789fe3ef0
e_sigabrt_act, sa_sigaction = 0x7f0789fe3ef0 e_sigabrt_act}, sa_mask =
{__val = {
0 repeats 16 times}}, sa_flags = -1073741820, sa_restorer = 0x0}
__FUNCTION__ = main
signature.asc
Description: OpenPGP digital signature
--
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=60134071iu=/4140/ostg.clktrk___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Enlightenment-release] Releases pending
Eduardo Lima (Etrunko) schrieb: Fresh new Enlightenment and Elementary. Also, not so new Ecore which was not sent to the ML. The black screen with old config still exists. md5sum 860e38f358cda23f40509f25a819d335 ecore-1.7.9.tar.bz2 8f9f8f74b8b899dd80d26fdb7008d89d ecore-1.7.9.tar.gz 589ade7ae89dc236976bfa0c25fcb84f elementary-1.7.9.tar.bz2 39fcd51f67b54cc1ebf7fcef4e2539ae elementary-1.7.9.tar.gz fe30d720080c3a7dd03ffc76a71d27af enlightenment-0.17.5.tar.bz2 195029366047e65150fb77c53bb35f63 enlightenment-0.17.5.tar.gz sha256sum f94b0d7146bdda8cc50ab8fa90b95b5039cd7a2ee349160517e484877364b1d1 ecore-1.7.9.tar.bz2 c754014f60edfa972dc2dd8318d3226239b1f53e7a77c3ef8660c70c576bd0a5 ecore-1.7.9.tar.gz 81a485fa6ed210df21eed9e6323efdcf85df12253bcee6f6e11593ae56efb0bc elementary-1.7.9.tar.bz2 7c47a794521b263f90ea80e3d8b330b90d9db3f8b696e470bd6965994d41b58d elementary-1.7.9.tar.gz 2eacc173090f256d14677c11ba81e1b58f5396ae9a42850c7232079152b35407 enlightenment-0.17.5.tar.bz2 7250d4f3f9b52e730d07f14521b131fd272f5a20cd3811ca76ace9f4c3233e39 enlightenment-0.17.5.tar.gz 2013/9/23 Eduardo Lima (Etrunko) ebl...@gmail.com: I have just uploaded new Evas tarballs which include latest texblock fixes from Tom. ae00f5eda9d9d2c7fc287b12babfc87b evas-1.7.9.tar.bz2 38f5add4539d8494807b17bfa6930977 evas-1.7.9.tar.gz 83b23239b46fa0c349a48dc6146927136578fa413530d084f5d1c269e6d4c63c evas-1.7.9.tar.bz2 e12f92acd344d5854f0b215cbc8740f1feef7e822ef87bfa8419fe012a25b164 evas-1.7.9.tar.gz Regards, Eduardo. 2013/9/18 Eduardo Lima (Etrunko) ebl...@gmail.com: 2013/9/18 Thomas Sachau to...@gentoo.org: Carsten Haitzler (The Rasterman) schrieb: On Fri, 13 Sep 2013 14:57:33 -0300 Eduardo Lima (Etrunko) ebl...@gmail.com said: It is already Friday the 13th, and I have not yet heard any feedbacks. Can we get this official release out of the doors by Tuesday? no. give it a few weeks. last release left people with systems that couldnt even stat e and had a blank screen. let's not do that again. Current status: fixed: -opengl+gles support with =mesa-9.1 (Gentoo Bug 462732) -e hanging prior to splash screen (Gentoo Bug 483194) -black screen on startup with multiscreen setup (might be the a duplicate of the previous one) (Gentoo Bug 484996) Still open: -black screen, when starting with an older config from before 0.17.4, while startup is fine with a new, clean config (Gentoo Bug 485268) Thanks for the report. :) I have updated the elementary tarballs with a couple of commits that went in today. md5sum 59b495e9a5f1736bb0e69d4f9e4acfc5 elementary-1.7.9.tar.bz2 ef8074cc3feca6fc5978984accffbbb2 elementary-1.7.9.tar.gz sha256sum fe5d673d7687e31862d6728de362fdb9bca5c5a660c2aa6c47e663ad92ae6dbd elementary-1.7.9.tar.bz2 89846ee721a23d9dd01cf18eff186ce5680cafe8fbe760a6869dd909c296c4d1 elementary-1.7.9.tar.gz Regards, Eduardo -- Eduardo de Barros Lima ◤✠◢ ebl...@gmail.com -- Eduardo de Barros Lima ◤✠◢ ebl...@gmail.com -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature -- 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=60134791iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Enlightenment-release] Releases pending
Carsten Haitzler (The Rasterman) schrieb: On Fri, 13 Sep 2013 14:57:33 -0300 Eduardo Lima (Etrunko) ebl...@gmail.com said: It is already Friday the 13th, and I have not yet heard any feedbacks. Can we get this official release out of the doors by Tuesday? no. give it a few weeks. last release left people with systems that couldnt even stat e and had a blank screen. let's not do that again. Current status: fixed: -opengl+gles support with =mesa-9.1 (Gentoo Bug 462732) -e hanging prior to splash screen (Gentoo Bug 483194) -black screen on startup with multiscreen setup (might be the a duplicate of the previous one) (Gentoo Bug 484996) Still open: -black screen, when starting with an older config from before 0.17.4, while startup is fine with a new, clean config (Gentoo Bug 485268) -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] e-0.17.0 segfault in e_border with efl-1.7.4
Carsten Haitzler (The Rasterman) schrieb: On Wed, 02 Jan 2013 23:07:01 +0100 Thomas Sachau to...@gentoo.org said: I have some more or less randomly happening segfaults of e (0.17.0 release) with efl libs (1.7.4 release), when a HUD shows over a window. It seems to happen more often, when the window itself gets moved, sample screenshot (HUD = the black boxes overlaying the window): http://sourceforge.net/apps/mediawiki/fpdb/nfs/project/f/fp/fpdb/d/dd/Fpdb_Table_with_HUD.JPG I got valgrind attached 2 times, once with a profile with some additional modules like forecasts and the second one with a clean profile. what hud where? The window with the blue border is from one app (actually a windows one, so running with wine under linux). All those black boxes (the one on the top left and all those relative to the players with some stats) are from a second app showing additional infos on top of the window of the first app. One can even open even more stats [1] which are then shown above both windows. When you take the window of the first app and move it around (which may cause the segfault more often, but not always), those additional stats go below this window, while the normal black boxes are still shown above it. [1]: http://sourceforge.net/apps/mediawiki/fpdb/nfs/project/f/fp/fpdb/a/a8/Fpdb_HUD_Popups_crop.JPG basically this is related to (it seems) the list of transient windows for a parent (dialogs etc.) and a hud could be a transient window - but what i dont have here is what causes the _e_border_sub_borders_new() to perhaps return stale border handles? that is built from the bd-transients list which SHOUDL be maintained by the border code, on deletion etc. too - but seemingly hasnt been in one or maybe more cases... those cases need finding. :) -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature -- 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_122712___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] e-0.17.0 segfault in e_border with efl-1.7.4
I have some more or less randomly happening segfaults of e (0.17.0 release) with efl libs (1.7.4 release), when a HUD shows over a window. It seems to happen more often, when the window itself gets moved, sample screenshot (HUD = the black boxes overlaying the window): http://sourceforge.net/apps/mediawiki/fpdb/nfs/project/f/fp/fpdb/d/dd/Fpdb_Table_with_HUD.JPG I got valgrind attached 2 times, once with a profile with some additional modules like forecasts and the second one with a clean profile. -- Thomas Sachau Gentoo Linux Developer ==9040== Memcheck, a memory error detector ==9040== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==9040== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==9040== Command: /usr/bin/enlightenment -valgrind -valgrind-log-file=test.log ==9040== Parent PID: 9039 ==9040== ==9052== ==9052== HEAP SUMMARY: ==9052== in use at exit: 7,732,953 bytes in 21,753 blocks ==9052== total heap usage: 46,681 allocs, 24,928 frees, 25,194,432 bytes allocated ==9052== ==9051== ==9051== HEAP SUMMARY: ==9051== in use at exit: 7,732,680 bytes in 21,750 blocks ==9051== total heap usage: 46,678 allocs, 24,928 frees, 25,194,155 bytes allocated ==9051== ==9052== LEAK SUMMARY: ==9052==definitely lost: 1,482 bytes in 5 blocks ==9052==indirectly lost: 6,720 bytes in 210 blocks ==9052== possibly lost: 0 bytes in 0 blocks ==9052==still reachable: 7,724,751 bytes in 21,538 blocks ==9052== suppressed: 0 bytes in 0 blocks ==9052== Rerun with --leak-check=full to see details of leaked memory ==9052== ==9052== For counts of detected and suppressed errors, rerun with: -v ==9052== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 3) ==9053== ==9053== HEAP SUMMARY: ==9053== in use at exit: 7,733,228 bytes in 21,756 blocks ==9053== total heap usage: 46,684 allocs, 24,928 frees, 25,194,709 bytes allocated ==9053== ==9051== LEAK SUMMARY: ==9051==definitely lost: 1,482 bytes in 5 blocks ==9051==indirectly lost: 6,720 bytes in 210 blocks ==9051== possibly lost: 0 bytes in 0 blocks ==9051==still reachable: 7,724,478 bytes in 21,535 blocks ==9051== suppressed: 0 bytes in 0 blocks ==9051== Rerun with --leak-check=full to see details of leaked memory ==9051== ==9051== For counts of detected and suppressed errors, rerun with: -v ==9051== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 3) ==9053== LEAK SUMMARY: ==9053==definitely lost: 1,482 bytes in 5 blocks ==9053==indirectly lost: 6,720 bytes in 210 blocks ==9053== possibly lost: 0 bytes in 0 blocks ==9053==still reachable: 7,725,026 bytes in 21,541 blocks ==9053== suppressed: 0 bytes in 0 blocks ==9053== Rerun with --leak-check=full to see details of leaked memory ==9053== ==9053== For counts of detected and suppressed errors, rerun with: -v ==9053== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 3) ==9054== ==9054== HEAP SUMMARY: ==9054== in use at exit: 7,733,504 bytes in 21,759 blocks ==9054== total heap usage: 46,687 allocs, 24,928 frees, 25,194,989 bytes allocated ==9054== ==9054== LEAK SUMMARY: ==9054==definitely lost: 1,482 bytes in 5 blocks ==9054==indirectly lost: 6,720 bytes in 210 blocks ==9054== possibly lost: 0 bytes in 0 blocks ==9054==still reachable: 7,725,302 bytes in 21,544 blocks ==9054== suppressed: 0 bytes in 0 blocks ==9054== Rerun with --leak-check=full to see details of leaked memory ==9054== ==9054== For counts of detected and suppressed errors, rerun with: -v ==9054== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 11 from 3) ==9063== Syscall param sendmsg(mmsg[0].msg_hdr) points to uninitialised byte(s) ==9063==at 0x829C0BF: sendmmsg (sendmmsg.c:36) ==9063==by 0x181842C3: __libc_res_nsend (res_send.c:1132) ==9063==by 0x18181B14: __libc_res_nquery (res_query.c:226) ==9063==by 0x181820D4: __libc_res_nquerydomain (res_query.c:582) ==9063==by 0x18182748: __libc_res_nsearch (res_query.c:378) ==9063==by 0x17F76A48: _nss_dns_gethostbyname4_r (dns-host.c:313) ==9063==by 0x8284380: gaih_inet (getaddrinfo.c:842) ==9063==by 0x8286C1D: getaddrinfo (getaddrinfo.c:2421) ==9063==by 0x5CA0FAA: ecore_con_info_get (ecore_con_info.c:283) ==9063==by 0x5CA1343: ecore_con_info_tcp_connect (ecore_con_info.c:130) ==9063==by 0x5C95049: ecore_con_server_connect (ecore_con.c:521) ==9063==by 0x10806B3D: _forecasts_cb_check (e_mod_main.c:572) ==9063== Address 0x7feffb4d0 is on thread 1's stack ==9063== Uninitialised value was created by a stack allocation ==9063==at 0x18183840: __libc_res_nsend (res_send.c:347) ==9063== ==9063== Syscall param write(buf) points to uninitialised byte(s) ==9063==at 0x6E16DAD: ??? (syscall-template.S:81) ==9063==by 0x5CA10AC: ecore_con_info_get (ecore_con_info.c:316) ==9063==by 0x5CA1343: ecore_con_info_tcp_connect (ecore_con_info.c:130) ==9063==by 0x5C95049
Re: [E-devel] [e-users] [Announce] Enlightenment DR 0.17-alpha4
Gustavo Sverzut Barbieri schrieb: On Wednesday, November 21, 2012, Carsten Haitzler wrote: On Wed, 21 Nov 2012 13:54:14 + Michael Blumenkrantz michael.blumenkra...@gmail.com javascript:; said: On Wed, Nov 21, 2012 at 1:47 PM, Carsten Haitzler ras...@rasterman.comjavascript:; wrote: On Wed, 21 Nov 2012 13:18:41 + Michael Blumenkrantz michael.blumenkra...@gmail.com javascript:; said: ah, how quickly bets are made against me the instant I leave the country. my league of admirers is always so reliable! distcheck is always run before a release. always. then how did it pass when the edje_cc in the 1.7 branch literally did crash in this scenario - it wasnt random. it literally was ALWAYS a strcmp against NULL... I said previously that I run the stable branch at work; I'm not at work. h so you didn't distcheck this one against stable branch? I'm on vacation, bedridden most of the time with the German Plague and a fever so high that the top of it can't be seen from the peak of Mt. Everest. Despite this, I managed to drag myself to my computer to try and do a release. I would appreciate greatly if people could stop being less negative and critical, and instead focus more on being both productive and constructive. fair enough - i just never expected this should even get through if you are building/testing against 1.7 - since you are not right now that dos create some issues and changes expectations that you are testing against that. :) How about you, Raster? Are you able to test with 1.7.x? You've mentioned this edje_cc bug and the Evas leaks. Anything else that is know but pending to be debugged in EFL (leaks, crashes) or we can do a 1.7.2? If doing a full release cycle for all released libs is too much work, what about just a minor release for edje (like version 1.7.1.1), so that users can again use release tarballs to build alpha4 of e17? -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Compiling recent E17 SVN
Andreas Volz schrieb: Hello, after several week I synced E17 SVN and tried to compile with easy_e17.sh as always: configure: error: Package requirements (eo) were not met: No package 'eo' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables EO_CFLAGS and EO_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. Seems there's a new package efl in trunk. I didn't read announcement about that structure change. When did it happen and was there an announcement? I think as many people use easy_e17.sh to cyclic compile e17 it should be announced. Maybe I missed it. Is there a new SVN compile instruction on the website that I could follow without looking deeper into efl and see what are the dependencies? regards Andreas Update your copy of easy_e17.sh (which you should always do, before you do even start (re)compiling anything from efl, then you should have a version, that includes the in your case missing eobj lib. If that is not the case, install eobj and go on. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
Carsten Haitzler (The Rasterman) schrieb: On Wed, 10 Oct 2012 21:52:30 +0200 Thomas Sachau to...@gentoo.org said: Tom Hacohen schrieb: On 10/10/12 11:11, Stefan Schmidt wrote: Hello. On 10/10/12 10:04, Tom Hacohen wrote: On 10/10/12 11:00, Stefan Schmidt wrote: Hello. On 10/10/12 09:50, David Seikel wrote: On Wed, 10 Oct 2012 09:37:00 +0100 Stefan Schmidt s.schm...@samsung.com wrote: Image loaders are way more complicated sadly as we drag in dependencies here. I would vote for making jpeg, png, gif, bmp, eet on by default. For the others we might need to see what libs distros ship in a default installation so we can decide if we have a hard dep on these libs or not. Better would be to remove the options, but detect them at build time to see if they should be included. Things should never be hard dependencies, unless they actually are. I see that you don't want to have this for your embedded project. :) But I disagree here. Autodetection is even worse in the case for the image loaders as your application will fail during runtime to load a theme or display thumbnails, etc. In your strictly controlled env this is not a problem as you can only blame yourself but in my opinion this is a no-no for almost all other users. Thus I would vote against autodetection and choose the hard deps carefully to fit the majority of our users. I'm also against autodetection. I prefer strict option setting. But you want to have them (all?) on by default and just let people disable them if needed. This would defeat the original purpose of removing options, right? :) regards Stefan Schmidt I think the ideas is to remove useless options, not useful. :) I'm not really against it, I'm fine with automagically detecting stuff if packagers don't find this annoying, the real question is: do they? Of course they do. automagic does mean, that you cant control, what actually happens, so you will never know, what a specific package will do. Just a basic example: Optional dependency installed, automagic package sees it, uses it, but user/developer/packager does not notice it, later the optional dependency gets removed. The result: broken automagic package and no way to properly fix this. for someone doing rpm pkging... you should know that this wont happen because rpm does auto deps... it ldd's everything looking for deps. As you can see in my sig, i do work on Gentoo Linux and until now, i dont create rpms but instead ebuilds, so this is no valid point. ;-) Beside that, it is also a valid point for creation of rpms, since the list of dependencies and features will then change, always depending on the currently installed list of optional dependencies of the packager. So if someone starts with a minimal system, he will have all optional features disabled, and a new build of the package later on with more optional packages installed would create a different result, since it includes more optional features and more dependencies. So again someone would have to check the build system itself for optional automagic dependencies, install them all before building packages for efl, just to be sure to always have the same result. And again, just forcing those dependencies would make it much easier for the packager, since the result does not vary depending on the current set of installed optional dependencies. So again: Either force-disable/force-enable a feature or allow configure switches for it, automagic just causes more confusion and more work for packagers and users. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl tree
Tom Hacohen schrieb: On 10/10/12 11:11, Stefan Schmidt wrote: Hello. On 10/10/12 10:04, Tom Hacohen wrote: On 10/10/12 11:00, Stefan Schmidt wrote: Hello. On 10/10/12 09:50, David Seikel wrote: On Wed, 10 Oct 2012 09:37:00 +0100 Stefan Schmidt s.schm...@samsung.com wrote: Image loaders are way more complicated sadly as we drag in dependencies here. I would vote for making jpeg, png, gif, bmp, eet on by default. For the others we might need to see what libs distros ship in a default installation so we can decide if we have a hard dep on these libs or not. Better would be to remove the options, but detect them at build time to see if they should be included. Things should never be hard dependencies, unless they actually are. I see that you don't want to have this for your embedded project. :) But I disagree here. Autodetection is even worse in the case for the image loaders as your application will fail during runtime to load a theme or display thumbnails, etc. In your strictly controlled env this is not a problem as you can only blame yourself but in my opinion this is a no-no for almost all other users. Thus I would vote against autodetection and choose the hard deps carefully to fit the majority of our users. I'm also against autodetection. I prefer strict option setting. But you want to have them (all?) on by default and just let people disable them if needed. This would defeat the original purpose of removing options, right? :) regards Stefan Schmidt I think the ideas is to remove useless options, not useful. :) I'm not really against it, I'm fine with automagically detecting stuff if packagers don't find this annoying, the real question is: do they? Of course they do. automagic does mean, that you cant control, what actually happens, so you will never know, what a specific package will do. Just a basic example: Optional dependency installed, automagic package sees it, uses it, but user/developer/packager does not notice it, later the optional dependency gets removed. The result: broken automagic package and no way to properly fix this. In the end packagers would have to force require all optional dependencies, so enabling all optional features, which is the same as doing it right away within the build system, just more annoying and time consuming for the packager. So either remove an option, force-disable or force-enable it for everyone or give it a configure option to control the feature. Just dont make it automagic without user control on the behaviour. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL Gentoo Packages
Gustavo Sverzut Barbieri schrieb: Hi all, I'd like to ask the official Gentoo maintainer of EFL packages to please update the portage to include the following: - EFL 1.7 (as per Rasterman's announcement, none of 1.7 are there, some released are missing) This would require some more work, since the tarballs are dirty and when i do this, then with clean and self created tarballs. Since there is yet no known ETA for a release of e17, there is a good chance for at least 1.7.1 efl release before an e17 release, so my questions is: Is it worth the additional work for 1.7.0? - Terminology 0.1 (as per Rasterman's announcement) This will probably require efl-1.7, right? - Python EFL 1.7 (as per my announcement today) Those will also require efl-1.7? - WebKit-EFL http://packages.profusion.mobi/webkit-efl/webkit-efl-svn-r127150.tar.bz2 this is required to build Elementary with web support (use flag). I'll take care to do a proper announcement later this week. From the comments i got on IRC, webkit-efl is not ready yet, beside that it requires versions for some dependencies which are not yet packaged for Gentoo. So currently not possible to create something, that can be supported. As for the existing overlays, I'd ask: - add to official overlay: - dev-libs/eio I already see that in there, was already added in 2010, maybe you should update your copy? ;-) - net-libs/webkit-efl See above - net-libs/azy Is this even used anywhere? - dev-util/clouseau Usefull for Gentoo users? - x11-themes/detourious - net-misc/econnman I can have a look into those. - dev-util/editje - dev-javascript/elev8 Anything using those? - dev-libs/ephysics - dev-db/esskyuehl Can also have a look into those. - rename to proper categories in official overlay: - expedite: x11-misc - app-benchmarks - elementary: x11-libs - media-libs I may do this, when i add a package to the main tree with a working release, but i see no reason to do those cosmetic changes in the overlay. I'm not sure about most E17 extra-modules, discomfitor/zmike was reviewing them for inclusion into core, then I'd assume everything that is outside of core should not be package as they are either unmaintained or do not work as expected. But he can say more about that. e.g. alarm, uptime, tclock and forecasts modules do work for me and i guess, there are more modules, which do work just fine. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Call for Packagers
Dennis.Yxun schrieb: On Sun, Sep 2, 2012 at 1:48 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Hi all, We have released EFL 1.7 and terminology 0.1, but to reach a broader audience we need binary packages! In order to keep quality and reduce overall pain, I'd try to coordinate this in our mail list with the following ideas: - don't create multiple PPA/OBS/overlays for the same distribution. Cooperate with others that want to help - those with official distro packager status could step in and help with their knowledge and rules. Ultimately we want these packages to be used by upstream of Ubuntu, Fedora, Suse, Arch and Gentoo. - the EFL developers could review build flags (optimizations) and compile options. This would ensure our packages are in good shape. - everybody could help with QA and test to ensure they work as expected. It would be nice to do some comparison such as benchmark expedite on the same HW with different distros. I'd like to have an updated list of official (as per our standards, if possible by distro as well) of EFL 1.7 and Terminology 0.1 packages. If you know of some distro people that would like to help but are not in this list, please share with him. Phoronix and Lwn would BR useful as well. BR, -- Gustavo -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel HI Barbieri: I'd like to help in Gentoo side, if I remember correctly there are three e overlay here 1) the gentoo's official which create/maintain ? by the gentoo developer vapier 2) the niifaq overlay, which is the most active, and I use it myself 3) also one overlay lay in E's repository?! if I remember correctly I would be great, if we can merge them all and push to gentoo's official tree Thanks Dennis I guess, you are a bit behind the development: 1. the main work for the official Gentoo overlay is done by me, Mike Blumenkrantz does also contribute there. 2. released versions of the core dependencies have already been moved from the overlay to the main tree for a long time now 3. the overlay in e-svn only contains some additions for the official Gentoo overlay, it is no full overlay by itself You can try to get the niifaq maintainers to move their content to the official Gentoo overlay, if you want to reduce the numbers. The official Gentoo overlay will stay for now, since it contains live ebuilds and ebuilds for none-core/not-released components. For the one in s-svn, you probably have to ask Mike Blumenkrantz, since he is maintaining that one. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Call for Packagers
Dennis.Yxun schrieb: On Sun, Sep 2, 2012 at 5:11 PM, Thomas Sachau to...@gentoo.org wrote: Dennis.Yxun schrieb: On Sun, Sep 2, 2012 at 1:48 AM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: Hi all, We have released EFL 1.7 and terminology 0.1, but to reach a broader audience we need binary packages! In order to keep quality and reduce overall pain, I'd try to coordinate this in our mail list with the following ideas: - don't create multiple PPA/OBS/overlays for the same distribution. Cooperate with others that want to help - those with official distro packager status could step in and help with their knowledge and rules. Ultimately we want these packages to be used by upstream of Ubuntu, Fedora, Suse, Arch and Gentoo. - the EFL developers could review build flags (optimizations) and compile options. This would ensure our packages are in good shape. - everybody could help with QA and test to ensure they work as expected. It would be nice to do some comparison such as benchmark expedite on the same HW with different distros. I'd like to have an updated list of official (as per our standards, if possible by distro as well) of EFL 1.7 and Terminology 0.1 packages. If you know of some distro people that would like to help but are not in this list, please share with him. Phoronix and Lwn would BR useful as well. BR, -- Gustavo -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel HI Barbieri: I'd like to help in Gentoo side, if I remember correctly there are three e overlay here 1) the gentoo's official which create/maintain ? by the gentoo developer vapier 2) the niifaq overlay, which is the most active, and I use it myself 3) also one overlay lay in E's repository?! if I remember correctly I would be great, if we can merge them all and push to gentoo's official tree Thanks Dennis I guess, you are a bit behind the development: 1. the main work for the official Gentoo overlay is done by me, Mike Blumenkrantz does also contribute there. Thanks for the information, I missed this, will investigate it 2. released versions of the core dependencies have already been moved from the overlay to the main tree for a long time now we are talking about the new 1.7.0 release, right? but those in main tree is quite old?! see followings dev-libs/e_dbus-1.1.0 dev-libs/eet-1.6.1 x11-libs/ecore-1.2.1 ... Those are simply the previous release versions, i will wait for the 1.7 addition until the issues with it reported by David Seikel have been fixed. 3. the overlay in e-svn only contains some additions for the official Gentoo overlay, it is no full overlay by itself then It's better merge into gentoo's official overlay, right? They are partly just experimental and partly due to different preference in category selection, for details, ask Mike Blumenkrantz -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] packaging
Am 19.03.2011 04:46, schrieb Mike Blumenkrantz: Hi, If you currently build/maintain packages for a distro, or know where they are located, please update this site with more correct information: http://trac.enlightenment.org/e/wiki/Operating_Systems The Gentoo Linux entry (Linux instructions) is outdated, official EFL ebuilds are in the main tree, official e17 snapshosts and live ebuilds for EFL and e17 are in the official overlay. Instructions for the overlay: http://overlays.gentoo.org/dev/vapier/wiki/enlightenment The (inofficial) gentoo-wiki seems to be dead, so might be better to drop that link. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d___ 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
Am 19.12.2010 04:51, schrieb Carsten Haitzler (The Rasterman): On Sat, 18 Dec 2010 17:14:02 +0100 Thomas Sachau to...@gentoo.org said: Attached is a build log with the failures. ok. since your position is that tests should work even if u enable them and they cant connect to a display, or that we need to go fine-graining tests just so you can --enable things that you wouldn't understand were they to fail, i've decided to remove all tests from src trees. I did not say exactly that. This is your view. I already told you, that packagers should test the package, before they add them and if upstream already has a test suite, it is the easiest way to test the package. As already said, tests should not require external services like X to run and if some tests need such a service, they should be skipped or there should be an option to skip them. And once you said, that those tests require an X server running as the same user, who does run the tests, i asked for making those tests optional, but at least you did not react to that reqest. it seems gentoo (some) users and/or developers are unable to take the hint of you enabled tests manually yourself - they are never enabled unless you explicitly enable them, then that makes it your problem. you shot yourself in the foot and then ask us why it hurts. we get the build logs that told you the problem (ecore_x_init fails - can't connect to a display somewhere) in the way intended (for developers to run test suites to see if they broke something fundamental while working on code), then that just wastes our time. See above for the tests requiring a running X server. Now, you removed the tests completly instead of adding an option to just skip the X-related tests. Also it does not seem like many devs actually used the ecore tests, now probably noone will use them and noone will find any issue with their usage. So in the end, it looks more like you did shoot yourself in the foot. i'm grumpy because i tried to explain it the short way (on irc) you enabled tests - they fail. don't enable them. if u cant run them in their expected test env they will fail. that fell on deaf ears, so the tests are summarily removed out of the src trees. if anyone has an issue with it - talk to thomas and/or gentoo developers. this week i replied to his issue twice. once in a trac ticket and again here. A simple those tests require running a X server as the same user and adding a way to skip those would be faster, easier and better for everyone. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP 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
Am 19.12.2010 14:16, schrieb Carsten Haitzler (The Rasterman): On Sun, 19 Dec 2010 13:26:21 +0100 Thomas Sachau to...@gentoo.org said: Am 19.12.2010 04:51, schrieb Carsten Haitzler (The Rasterman): On Sat, 18 Dec 2010 17:14:02 +0100 Thomas Sachau to...@gentoo.org said: packagers should test the package, before they add them and if upstream already has a test suite, it is the easiest way to test the package. As already said, tests should not require external services like X to run and if some tests need such a service, they should be skipped or there should be an option to skip them. And once you said, that those tests require an X server running as the same user, who does run the tests, i asked for making those tests optional, but at least you did not react to that reqest. because i had already told you that you shouldnt be enabling the tests as they are not for you. they are not for packagers. the basis for your request is that you SHOULD run them and that x ones are bad and shouls be disabled from normal tests etc. etc. - i didnt response because the entire premise that you should be running the test suite in an ebuild is wrong in the first place. There is just the OPTION to run those tests inside the ebuild, no suggestion and no requirement for that. You said, they are for developers to see, if they broke something. So running those tests should not harm any packager or user. But if some dev did not run the tests and broke something, it will prevent others from installing this broken version. i'm grumpy because i tried to explain it the short way (on irc) you enabled tests - they fail. don't enable them. if u cant run them in their expected test env they will fail. that fell on deaf ears, so the tests are summarily removed out of the src trees. if anyone has an issue with it - talk to thomas and/or gentoo developers. this week i replied to his issue twice. once in a trac ticket and again here. A simple those tests require running a X server as the same user and adding a way to skip those would be faster, easier and better for everyone. they dont require an xserver of the same user id - they require to be able to connect to an xserver. doesn't matter who/where.. as long as DISPLAY specifies an xserver you can connect to. Let me quote you from last night: rasterjust because DISPLAY is inherited in the build doesnt mean that the build even runs as your UID rasternor that it inherits the sams x authatiry rasterx authority I did add a second X server for the user running the tests and they do work that way. All i needed was this info. Please try to stay at the technical level in the future. Just writing 1 or 2 lines about the requirements of ecore_x tests would have saved all of us a good amount of time and would not have raised the barrier for developers to run the tests. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP 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] backtraces for e segfaults/crashes
Am 12.12.2010 02:20, schrieb Carsten Haitzler (The Rasterman): On Sat, 11 Dec 2010 17:24:48 +0100 Thomas Sachau to...@gentoo.org said: Since irc currently seems a bit silent, let me post the last 2 backtraces here, so someone can have a look and either fix those issues or point me to the issue i have on my machine, both backtraces first contain the bt and afterwards a bt full, both with gdb attached to the crashed/segfaulted e. unfortunately both traces say the bug happened somewhere else earlier and memory has been stomped over and is later causing this crash. you'll want/need to run e using valgrind to help spot the original point of error. note - before you do tyhis ensure that you have everything up to date and built in-sync (ie updated to the same svn revision for everything and all rebuilt - gdb debugging on, also you might want to limit optimization to -O, not -O2 or -O3 - no inlining). that may give the actual problem. http://trac.enlightenment.org/e/wiki/Debugging for how to run a 2nd X (or even use Xephyr instead as your 2nd X). Valgrind does not help in this case, since i am not able to produce those problems with e running inside of valgrind. I can produce it without the slowdown of valgrind without problems. So the problem may be a race condition. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] backtraces for e segfaults/crashes
Since irc currently seems a bit silent, let me post the last 2 backtraces here,
so someone can have
a look and either fix those issues or point me to the issue i have on my
machine, both backtraces
first contain the bt and afterwards a bt full, both with gdb attached to
the crashed/segfaulted e.
--
Thomas Sachau
Gentoo Linux Developer
#0 0x6f9a8625e12e in __lll_lock_wait_private () from /lib/libc.so.6
#1 0x6f9a861f9442 in _L_lock_9796 () from /lib/libc.so.6
#2 0x6f9a861f7811 in __libc_free (mem=0x6f9a864e7e40) at malloc.c:3736
#3 0x6f9a86de5988 in _XReply () from /usr/lib/libX11.so.6
#4 0x6f9a86de0722 in XSync () from /usr/lib/libX11.so.6
#5 0x6f9a8951eddf in ecore_x_sync () at ecore_x.c:816
#6 0x0052134b in e_sigabrt_act (x=6, info=0x7516b26edf70,
data=0x7516b26ede40) at e_signals.c:212
#7 signal handler called
#8 0x6f9a861b27a5 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#9 0x6f9a861b3c26 in abort () at abort.c:92
#10 0x6f9a861ed4f4 in __libc_message (do_abort=2, fmt=0x6f9a862adac0 ***
glibc detected *** %s: %s: 0x%s ***\n)
at ../sysdeps/unix/sysv/linux/libc_fatal.c:186
#11 0x6f9a861f2976 in malloc_printerr (action=3, str=0x6f9a862aac14
corrupted double-linked list, ptr=value optimized out) at malloc.c:6283
#12 0x6f9a861f43d5 in _int_free (av=0x6f9a864e7e40, p=0xbbea30) at
malloc.c:4973
#13 0x6f9a861f781c in __libc_free (mem=value optimized out) at
malloc.c:3738
#14 0x6f9a86b8dbd1 in _XShmDestroyImage (ximage=0xbbea40) at XShm.c:265
#15 0x6f9a89a65368 in evas_software_xlib_x_output_buffer_free
(xob=0xad1d70, sync=0) at evas_xlib_buffer.c:385
#16 0x6f9a89a616c0 in _clear_xob (sync=0) at evas_xlib_outbuf.c:146
#17 0x6f9a89a632be in evas_software_xlib_outbuf_idle_flush (buf=0xc8a800)
at evas_xlib_outbuf.c:803
#18 0x6f9a89a60d4d in eng_output_idle_flush (data=0xa1c660) at
evas_engine.c:847
#19 0x6f9a899f10cd in evas_render_idle_flush (e=0xa1c1e0) at
evas_render.c:1489
#20 0x6f9a892f02cb in _ecore_evas_cb_idle_flush (data=0xa1ba40) at
ecore_evas.c:2826
#21 0x6f9a8975f972 in _ecore_timer_call (when=160155.813068816) at
ecore_timer.c:564
#22 0x6f9a8975cc29 in _ecore_main_loop_iterate_internal (once_only=0) at
ecore_main.c:1366
#23 0x6f9a8975b6b2 in ecore_main_loop_begin () at ecore_main.c:651
#24 0x0042ec6a in main (argc=1, argv=0x7516b26f21e8) at e_main.c:1158
#0 0x6f9a8625e12e in __lll_lock_wait_private () from /lib/libc.so.6
No symbol table info available.
#1 0x6f9a861f9442 in _L_lock_9796 () from /lib/libc.so.6
No symbol table info available.
#2 0x6f9a861f7811 in __libc_free (mem=0x6f9a864e7e40) at malloc.c:3736
ar_ptr = 0x6f9a864e7e40
p = 0xcf8a60
hook = value optimized out
#3 0x6f9a86de5988 in _XReply () from /usr/lib/libX11.so.6
No symbol table info available.
#4 0x6f9a86de0722 in XSync () from /usr/lib/libX11.so.6
No symbol table info available.
#5 0x6f9a8951eddf in ecore_x_sync () at ecore_x.c:816
No locals.
#6 0x0052134b in e_sigabrt_act (x=6, info=0x7516b26edf70,
data=0x7516b26ede40) at e_signals.c:212
No locals.
#7 signal handler called
No symbol table info available.
#8 0x6f9a861b27a5 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
resultvar = 0
pid = value optimized out
selftid = 28946
#9 0x6f9a861b3c26 in abort () at abort.c:92
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x7516b26ee370, sa_sigaction
= 0x7516b26ee370}, sa_mask = {__val = {128740343341920, 128740343358663, 22,
122709466595807, 3, 128740343341930, 6, 122709466595811, 2,
128740343341918, 2, 122709466586949, 1, 122709466595807, 3, 128740343341924}},
sa_flags = 12, sa_restorer = 0x6f9a862ac1e3}
sigs = {__val = {32, 0 repeats 15 times}}
#10 0x6f9a861ed4f4 in __libc_message (do_abort=2, fmt=0x6f9a862adac0 ***
glibc detected *** %s: %s: 0x%s ***\n)
at ../sysdeps/unix/sysv/linux/libc_fatal.c:186
ap = {{gp_offset = 40, fp_offset = 48, overflow_arg_area =
0x7516b26eece0, reg_save_area = 0x7516b26eebf0}}
ap_copy = {{gp_offset = 16, fp_offset = 48, overflow_arg_area =
0x7516b26eece0, reg_save_area = 0x7516b26eebf0}}
fd = 20
on_2 = value optimized out
list = value optimized out
nlist = value optimized out
cp = value optimized out
written = value optimized out
#11 0x6f9a861f2976 in malloc_printerr (action=3, str=0x6f9a862aac14
corrupted double-linked list, ptr=value optimized out) at malloc.c:6283
buf = 00bbeac0
cp = value optimized out
#12 0x6f9a861f43d5 in _int_free (av=0x6f9a864e7e40, p=0xbbea30) at
malloc.c:4973
size = 144
fb = value optimized out
nextchunk = 0xbbeac0
nextsize = 32
nextinuse = value optimized out
prevsize = value optimized out
bck
Re: [E-devel] ANNOUNCE: EFL Beta2 release
Am 12.11.2010 19:24, schrieb Jeff Hoogland: I would be willing to help package and maintain Enlightenment/EFL for Debian/Ubuntu if we could get functional debian control files and the such into the build. Why does debian/ubuntu need additional files special for debian in the release tarballs? Those should be distro independent and every distro should the packaging itself or did i miss something here? ~Jeff Hoogland - Original message - Hey guys, kudos to Cedric and everyone else involved in making the release, announcement is below: BETA2 Release of core EFL Nov 12, 2010 at 08:30 AM Enlightenment must come little by little -- otherwise it would overwhelm. -- Idries Shah We're excited to announce the second beta release of the Enlightenment Foundation Libraries. After a huge amount of work by our developers, we are finally approaching the 1.0 release, and we're asking for the community to help test this version in the widest array possible of configurations so that we can be confident our final product will be rock-solid! Since i have not seen any feedback recently, the randr related issues i have reported are probably still around and need to be fixed. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Another beta
Am 02.11.2010 19:06, schrieb Cedric BAIL: Hi everyone, I would like to do another beta during next week. As raster as a lot of work and will not have the time required to do it, I would like that this one put less burden on him. So I will try to do the tarball and will request help from people to test them before putting them online. I would like someone else to take on writing the content of the news and we should synchronize our work for that one. But before doing that, I would like to see a few bugs to be gone and maybe you have some of your bugs that you want to see gone for this beta : - eina: should now be portable and eina_file_*ls API should be fine. Could you try on your OS that this is the case and report any issue. - e17: - focus issue: we have a lot of focus issue. When switching from one desktop to another, sometime the window with the focus doesn't receive keyboard input. When moving windows from one desktop to another, sometime the windows that we are moving loose the focus and it's another one that we end up moving. When you switch from one desktop to another, sometime a sticky window will loose the focus. - lock issue: in some condition, the lock code doesn't detect key press and lock the screen when you are actively working. - everything: when closing the window, e17 just segv. I know that the bug are mostly e17 bugs, but as we will provide snapshot of e17, it's good to have a quality for that one too. I would also like to include snapshot of elementary, ephoto, eve, python and javascript bindings. So if you have bugs/concern regarding any of this project please raise your hand ! It would also be nice to have the randr related bugs i have found and sent with a bt to this list fixed. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature -- Achieve Improved Network Security with IP and DNS Reputation. Defend against bad network traffic, including botnets, malware, phishing sites, and compromised hosts - saving your company time, money, and embarrassment. Learn More! http://p.sf.net/sfu/hpdev2dev-nov___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] 2 Backtraces (crashes/segfaults of e17)
Am 20.10.2010 22:01, schrieb Leif Middelschulte:
Hello Thomas,
at the moment I don't have access to an external monitor for further
debugging of the randr mode setting issue. Last time I had access to
an external monitor, I traced it down to a wrong events sent by my
driver for some reason.
It looks like your driver doesn't send mode names. Attached patch
fixes their freeing.
BR,
Leif
P.S.: Further patches for RandR follow as soon, as I have access to an
external monitor again.
I have the patch attached, but during testing, i get another e crash/loop, same
app as above, but
this time, e starts to use 100% of one core and doesnt react to any input any
more. This also
happened before, so does not have to be related to your patch at all.
See attached bt for some details.
--
Thomas Sachau
Gentoo Linux Developer
#0 _e_randr_output_modes_add (output_info=0x7f76f0) at e_randr.c:555
#1 0x005120b8 in _e_randr_output_info_hw_info_set
(output_info=0x7f76f0) at e_randr.c:1670
#2 0x0050fc81 in _e_randr_event_cb (data=0x0, type=58, ev=0xadfde0) at
e_randr.c:796
#3 0x65ceb61e414c in _ecore_event_call () at ecore_events.c:597
#4 0x65ceb61eb124 in _ecore_main_loop_iterate_internal (once_only=0) at
ecore_main.c:1356
#5 0x65ceb61e99b5 in ecore_main_loop_begin () at ecore_main.c:573
#6 0x0042ff5b in main (argc=1, argv=0x75b3ac933928) at e_main.c:1156
#0 _e_randr_output_modes_add (output_info=0x7f76f0) at e_randr.c:555
modes = 0xba7af0
mode_info = 0x7f7320
nmodes = 63
npreferred = 0
iter = 0xebb070
added_yet = 0 '\000'
#1 0x005120b8 in _e_randr_output_info_hw_info_set
(output_info=0x7f76f0) at e_randr.c:1670
outputs = 0x0
crtcs = 0x7f71e4
output = 0x7f71e0
crtc = 0x0
i = 0
num = 0
#2 0x0050fc81 in _e_randr_event_cb (data=0x0, type=58, ev=0xadfde0) at
e_randr.c:796
event = 0xadfde0
restore_info = 0x8baa30
output_info = 0x7f76f0
crtc_info = 0x7f7790
enabled = 0 '\000'
#3 0x65ceb61e414c in _ecore_event_call () at ecore_events.c:597
ret = 1 '\001'
eh = 0x7f72a0
e = 0xdcd3e0
handle_count = 1
l = 0x65ceb61eacdb
l_next = 0x75b3ac930680
eh = 0x7f30d704fcb73bbf
#4 0x65ceb61eb124 in _ecore_main_loop_iterate_internal (once_only=0) at
ecore_main.c:1356
next_time = -1
have_event = 1
have_signal = 0
#5 0x65ceb61e99b5 in ecore_main_loop_begin () at ecore_main.c:573
No locals.
#6 0x0042ff5b in main (argc=1, argv=0x75b3ac933928) at e_main.c:1156
i = 1
nostartup = 0
after_restart = 0
safe_mode = 0
buf =
/usr/share/enlightenment/data/icons\000\000e\000\000\330\355\266\265\316e\000\000\230\240\223\266\316e\000\000\342\237v\266\316e\000\000\000\200\227\266\316e\000\000\000\220\227\266\316e\000\000\260\246\227\266\316e\000\000\000P\227\266\316e\000\000\000\020\224\266\316e\000\000\000\340\223\266\316e,
'\000' repeats 11 times\200,
\227\266\316e\000\000\003\000\000\000\000\000\000\000`\a\267\265\316e\000\000p)\223\254\263u\000\000\000\000\200PYg\353\000\000\266q\355l\235\313R\020\211\023\000L\\225\000\000\000\000\037\000\000\000\\000\000\000#\000\000\000(\000\000\000\000\000\000\000\020\067\223\254\263u\000\000\200\067\223\254\263u\000\000\250\231\227\266\316e\000\000\a\000\000\000\000\000\000\000C\205\327\265\316e\000\000p*\223\254\263u\000\000\215\234v\266\316e\000\000\000\000\000\000\000\000\000\000\066O\373\033rZhV\000\000\000\000\000\000\000\000\366...
s = 0x75b3ac934a3d :0
action = {__sigaction_handler = {sa_handler = 0x52215a e_sigabrt_act,
sa_sigaction = 0x52215a e_sigabrt_act}, sa_mask = {__val = {
0 repeats 16 times}}, sa_flags = -1073741820, sa_restorer =
0x65ceb69404d8}
t = 1287678882.9203961
tstart = 1287678882.9203961
signature.asc
Description: OpenPGP digital signature
--
Nokia and ATT present the 2010 Calling All Innovators-North America contest
Create new apps games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] 2 Backtraces (crashes/segfaults of e17)
The first one only occured once, seems to be evas related and i cannot easily
reproduce it.
The second one is randr related and i can reproduce it in a good amount of
cases, usually when i
start an older game in wine in fullscreen mode, where the aspect ration gets
adjusted by the nvidia
drivers (a 4:3 fullscreen doesnt look that well on a 16:9 screen). If e17 does
not crash during that
game, i can exit the game without problems. But once i try to exit e17, i get
the second bt, which
results in e17 not reacting to any input (requires a kill -9 to stop it).
--
Thomas Sachau
Gentoo Linux Developer
#0 0x673b181793d3 in __poll (fds=value optimized out, nfds=value
optimized out, timeout=value optimized out) at
../sysdeps/unix/sysv/linux/poll.c:87
#1 0x673b1589ea7a in _xcb_conn_wait (c=0x7a9610, cond=value optimized
out, vector=0x0, count=0x0) at xcb_conn.c:313
#2 0x673b158a04f8 in xcb_wait_for_event (c=0x7a9610) at xcb_in.c:535
#3 0x673b18d1ac78 in _XReadEvents (dpy=0x79c590) at xcb_io.c:341
#4 0x673b18cfd648 in XNextEvent (dpy=0x79c590, event=0x73a07657a010) at
NextEvent.c:51
#5 0x0043ad1f in e_alert_show (
text=0x5142d8 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:146
#6 0x004e0ac9 in e_sigseg_act (x=value optimized out, info=value
optimized out, data=value optimized out) at e_signals.c:129
#7 signal handler called
#8 eina_rbtree_delete (root=0x31312e33312e3637, func=0x673b19cabd10
_eina_hash_head_free, data=0xd58e20) at eina_rbtree.c:585
#9 0x673b19cac2cc in eina_hash_free (hash=0xd58e20) at eina_hash.c:1031
#10 0x673b1b8f21cf in _evas_common_font_int_free (fi=0xde8300) at
evas_font_load.c:85
#11 0x673b19cab637 in _eina_hash_el_free (hash_element=0xde83a8,
hash=value optimized out) at eina_hash.c:396
#12 0x673b19cab957 in _eina_hash_del_by_hash_el (hash=0x99a130,
hash_element=0xde83a8, hash_head=0xde8380, key_hash=-927478372) at
eina_hash.c:419
#13 0x673b19cabb3b in _eina_hash_del_by_key_hash (hash=0x99a130, key=value
optimized out, key_length=value optimized out, key_hash=-927478372,
data=value optimized out) at eina_hash.c:469
#14 0x673b1b8f2331 in evas_common_font_flush () at evas_font_load.c:827
#15 0x673b1b8f24ed in evas_common_font_free (fn=0xde5610) at
evas_font_load.c:603
#16 0x673b1b8b7f08 in evas_fonts_zero_presure (evas=0xac3180) at
evas_font_dir.c:164
#17 0x673b1b8bec35 in evas_render_idle_flush (e=0xac3180) at
evas_render.c:1485
#18 0x673b1b1cf9d1 in _ecore_evas_cb_idle_flush (data=value optimized
out) at ecore_evas.c:2826
#19 0x673b1b6355aa in _ecore_timer_call (when=value optimized out) at
ecore_timer.c:552
#20 0x673b1b632a29 in _ecore_main_loop_iterate_internal (once_only=0) at
ecore_main.c:1213
#21 0x673b1b632f37 in ecore_main_loop_begin () at ecore_main.c:568
#22 0x0042f94b in main (argc=value optimized out, argv=value
optimized out) at e_main.c:1156
#0 0x673b181793d3 in __poll (fds=value optimized out, nfds=value
optimized out, timeout=value optimized out) at
../sysdeps/unix/sysv/linux/poll.c:87
resultvar = 18446744073709551100
oldtype = 0
result = value optimized out
#1 0x673b1589ea7a in _xcb_conn_wait (c=0x7a9610, cond=value optimized
out, vector=0x0, count=0x0) at xcb_conn.c:313
ret = 22
fd = {fd = 5, events = 1, revents = 0}
#2 0x673b158a04f8 in xcb_wait_for_event (c=0x7a9610) at xcb_in.c:535
ret = 0x0
#3 0x673b18d1ac78 in _XReadEvents (dpy=0x79c590) at xcb_io.c:341
event = 0x73a07657a010
response = value optimized out
serial = 35
#4 0x673b18cfd648 in XNextEvent (dpy=0x79c590, event=0x73a07657a010) at
NextEvent.c:51
No locals.
#5 0x0043ad1f in e_alert_show (
text=0x5142d8 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:146
w = 170
i = value optimized out
j = value optimized out
k = value optimized out
line =
\274\241Wv\240s\000\000\344\211Y\032;g\000\000\274\241Wv\240s\000\000\270\241Wv\240s\000\000\300\241Wv\240s\000\000\304\241Wv\240s\000\000\024\241Wv\240s\000\000\300\364\275\000\000\000\000\000\060\000\000\000\060\000\000\000\000\242Wv\240s\000\000\060\241Wv\240s\000\000f\031\327\230y\267\257B\374\234\330\000\000\000\000\000\214\310\215\033;g\000\000\240\322\230\000\000\000\000\000f\031\327\230y\267\257Bd\242Wv\240s\000\000\300K\333\000\000\000\000\000\020x\271\000\000\000\000\000\\000\000\000\000\000\000\000\\000\000\000\000\000\000\000}1\216\033;g\000\000\\000\000\000\000\000\000\000f\031\327\230y\267\257B\020x\271\000\000\000\000
Re: [E-devel] Issues with svn content for varous packages
On 03/04/2010 02:23 AM, Carsten Haitzler (The Rasterman) wrote: On Wed, 03 Mar 2010 19:20:13 +0100 Thomas Sachau to...@gentoo.org said: Hi, i tried to compile all packages, which are as ebuilds in official Gentoo enlightenment overlay from svn and i found some issues, which i will list below: Missing README file, when README.in exists, lets automake bail out: if you used the autogen.sh we provide - it'd work. but you aren't. :) so.. i'd say this is your problem. (our autogen.sh touches README to get around this pedanticism in autofoo). You used the right word: get around, it is just a workaround for a bug in your repo, independent on how you call it or where you point at. The autogen.sh itself is also a workaround too, i use eautoreconf (a function for Gentoo ebuilds doing basicly the same as autoreconf) for months now, there is no problem with autotools themselves. eet embryo imlib2_loaders ecore evas autogen.sh containing lines, which hide issues in svn (like removing autotools related files or touching README), the issues should be fixed themselves, not worked around in autogen.sh: wrong. this is a pedanticism that is just there to be a pain. we want README versioned - thus generated from the .in file when we do things like make dist etc. so... if you choose to be pedantic - you get to live with the consequences as our ideas and autofoo's developers disagree - and we fix that up in autogen.sh. autotools isnt quite doing what we want and so we work around it. :) the rm's are there due to issues encountered years back and i'm not going to remove something that works - as all you do is run into the same bug again eventually and end up having to fix it again as above. if it ain't broke - don't fix it. as our work isnt working on autofoo - we work around it where we can. The removal of autotools files does just hide it, when someone does commit them, also they should not committed in the first place. Drop the line and you directly get it on next rebuild try, else you will never see the issue. Do you really want to hide bugs with workaround instead of fixing them? For README: Creating an empty README file in the repo will really fix the issue and does not create any pain with versioned README. Touching it in autogent.sh is also just a workaround hiding the real issue. And there was some bug some years ago realated to this is no argument at all, you did not in any way show us a link to the bug, not exactly how it showed up nor how it could be happen again today. With your aint broken, dont fix it attitude, you could also argue to not update anything. Why would you start development of e17, e16 did work and still does work, doesnt it? eet embryo imlib2_loaders ecore evas Packages checking for ecore-data, which is now disabled by default: ewl wlan module happy to have them break as they are not being maintained actively. 3rd party modules in E-MODULES-EXTRa are the responsibility of the person who put them in - people insisted on wanting svn to put their modules into - so we allowed it and then the vast majority of these maintainers/developers vanished. dont build things from e-modules-extra. we dont intend to release anything from there - so dont expect any support for things there. we will release what is needed for e17 only - and this isn't. (added - elementary will get a 1.0 too). You have commit powers, i dont, so i report those. It is upon you (or anyone else with svn access) to fix them or not, but you cannot tell me, that you did not know about them. Makefile.am containing ACLOCAL_AMFLAGS = -I m4, also that dir does not exist: execwatch module mpdule module winselector module same as above. if you want to build all of these you are on your own. upstream isnt supporting them. we are supporting: eina, eet, evas, ecore, embryo, edje, efreet, e_dbus, e added bonus: elementary As above: I dont have access, so all i can do is reporting it, fixing is on your (=e upstream) side. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP 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
[E-devel] Issues with svn content for varous packages
Hi, i tried to compile all packages, which are as ebuilds in official Gentoo enlightenment overlay from svn and i found some issues, which i will list below: Missing README file, when README.in exists, lets automake bail out: eet embryo imlib2_loaders ecore evas autogen.sh containing lines, which hide issues in svn (like removing autotools related files or touching README), the issues should be fixed themselves, not worked around in autogen.sh: eet embryo imlib2_loaders ecore evas Packages checking for ecore-data, which is now disabled by default: ewl wlan module Makefile.am containing ACLOCAL_AMFLAGS = -I m4, also that dir does not exist: execwatch module mpdule module winselector module -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP 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
